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Mission  control  and  management  is  becoming  an  increasingly  important  subject  in  vehicle  guidance  and  control.  Developments 
in  this  field  provide  crucial  contributions  to  the  improvement  of  mission  effectiveness.  These  are  related  to  single  air  vehicle 
missions  or  to  multiple  air  vehicle  missions  (including  air  traffic),  and  to  the  whole  missions  or  the  mission  elements. 

The  subject  covers  both  the  ground  segment  and  the  air  vehicle  segment  of  the  complete  system,  with  highly  integrated  concepts 
embracing  ground-based  and  onboard  system  elements,  being  particularly  relevant  The  ground  segment  typically  comprises  a 
number  of  elements  such  as  pre-mission  tasking  and  planning,  ground-based  information  sources,  situation  assessment  and 
mission  plan  upgrading.  The  air  vehicle  segment  comprises  the  onboard  mission  control  and  management,  including  situation 
assessment  capabilities,  automatic  mission  planning  and  plan  execution  functions.  The  onboard  system  may  be  used  as  an  aid  to 
the  pilot  in  mission  planning  and  tactical  decision  making  or,  in  the  case  of  an  unmanned  vehicle,  may  be  fully  automated. 

The  technical  papers  addressed  the  current  developments  and  trends  in  air  vehicle  mission  management,  assessed  the  state-of- 
the-art  and  identified  technological  alternatives  for  future  systems.  System  application  issues  are  of  primary  importance.  The 
following  topics  fell  within  the  scope  of  the  symposium:  air  vehicle  missions,  situation  assessment  technology,  mission  planning 
and  execution,  system  implementation  for  mission  control/management. 
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La  gestion  et  le  controle  des  missions  revet  de  plus  en  plus  d’importance  dans  le  guidage  et  le  pilotage  des  vehicules  aeriens.  Les 
developpements  dans  ce  domaine  representent  des  contributions  d'une  importance  capitate  pour  I'optimisation  de  la  conduite 
des  missions.  Ils  concernent  des  missions  soil  a  vecteur  unique,  soil  a  vecteur  multiple  (y  compris  le  trafic  aerien)  et  ils 
s’appiiquent  soit  a  la  totalite  de  la  mission,  soit  a  certains  elements  de  ceile-ci. 

Le  sujet  couvre  le  segment  sol  et  le  segment  vehicule  aerien  du  systeme  complet,  oil  la  conception  hautement  integree  des 
elements  du  systeme,  tant  embarques  qu’au  sol,  est  particulierement  significative.  Le  segment  sol  comprend  typiquement  un 
certain  nombre  d’elements  tels  que  1'assignation  des  taches  et  la  planification  avant  vol,  les  sources  d’informations  au  sol, 
revaluation  de  la  situation  et  la  mise  a  jour  du  plan  de  mission.  Le  segment  vehicule  aerien  comprend  la  gestion  et  le  controle  de 
la  mission  par  des  moyens  aeroportes,  y  compris  revaluation  de  la  situation,  la  planification  automatique  de  la  mission  et 
I’execution  du  plan  de  mission.  Le  systeme  aeroporte  peut  soit  servir  d’aide  au  pilote  pour  la  planification  de  la  mission  et  la 
prise  de  decisions  tactiques,  soit,  dans  le  cas  d’un  vehicule  non-pilote,  fonctionner  en  mode  automatique. 

Les  communications  techniques  ont  examine  les  realisations  et  les  tendances  actuelles  dans  le  domaine  de  la  gestion  des 
missions  des  vehicules  aeriens.  presente  I’etat  de  1’art  et  propose  des  solutions  technologiques  pour  la  conception  des  systemes 
futurs.  Une  attention  toute  particuliere  a  ete  accordee  aux  questions  concemant  les  applications.  Le  symposium  a  porte  sur  les 
sujets  suivants:  les  missions  des  vehicules  aeriens,  les  techniques  devaluation  de  la  situation,  la  planification  et  1’execution  de  la 
mission,  et  la  mise  en  oeuvre  des  systemes  de  gestion/ controle  des  missions. 
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KEYNOTE  ADDRESS 

by 

Major-General  W.  Breeschoten 

Ministerie  van  Defensie  (KLu) 
Luchtmachstaf 
PO  Box  20703 
2500  Es  Den  Haag 
The  Netherlands 


I.  INTRODUCTION 
Ladles  and  Gentlemen, 

In  addition  to  my  present  function  as  Director 
Operations  of  the  RNLAF  I  am  a  fighter  pilot. 

This  week  you  will  be  discussing  my  job;  the 
management  and  control  of  missions . 

Therefore  I  was  pleased,  both  with  the  subject  of 
this  symposium  and  with  your  kind  Invitation  to 
address  you  at  the  beginning  of  this  week. 

In  this  address  I  will  start  with  my  views  as  a 
pilot  on  the  subject  of  mission  control  support 
systems,  (you  already  noted  the  word  support)  and 
work  towards  my  views  as  Director.  These  views 
are  the  same,  only  the  scope  is  different. 

II.  MISSION  CONTROL  AND  THE  PILOT 

As  a  pilot,  or  group  of  pilots  I  get  assigned  a 
mission,  say  to  attack  a  certain  ground  target 
with  the  objective  to  destroy  it,  or  make  it 
unusable  for  a  certain  period  of  time.  My  job 
Chen  is  to  prepare  and  execute  this  mission. 

My  preparation  consists  largely  of  building  up  an 
image  of  what  precisely  is  required  and  under 
what  circumstances. 

For  this  I  collect  information  on  the  situation 
enroute,  the  situation  at  the  target,  the 
assistance  that  can  be  expected  from  supporting 
forces  and  when,  the  weather  situation  and  so  on. 

Then  the  mission  is  planned,  which  concerns  a 
multitude  of  items: 

route  selection,  flight  profile  planning,  weapons 
selection  and  attack  profile  planning,  planning 
for  mutual  protection  ,  planning  for  ECM 
employment,  planning  for  threat  system  counters, 
not  to  mention  planning  for  relative  timing  and 
required  command  and  Information  exchanges  with 
my  companions  with  supporting  units  and  with 
other  missions. 

Now  I  know  what  I  can  expect  during  my  mission 
and  how  to  manage  possible  situations.  Also  I 
know  how  these  situations  can  be  identified, 
using  my  on-board  sensor  data.  For  situations 
that  can  be  anticipated  I  know  what  I  am  supposed 
to  do  and  how  to  do  it. 

During  lxecution  I  use  the  preparation  results  in 
conjunction  with  my  system  displays  and  my  mkl 
eyeball  to  maintain  an  image  of  the  situation, 
assess  its  meaning  for  my  mission,  decide  on 
actions  and  of  course  carry  them  out . 

This  process,  from  preparation  to  execution,  is 
called  mission  control.  In  the  complex  technical 
ana  operational  environment  of  today  and  tomorrow 
I  can  do  with  some  nelp  when  doing  it. 

First  of  all  in  the  field  of  informetlon  during 
preparation.  The  more  I  know,  the  less  surprises, 
and  the  larger  the  chance  of  a  successful 
mission.  Therefore  information  must  be  recent, 
reliable,  and  preferably  accurate  and  complete. 


Moat  of  all  it  must  be  easy  to  interpret. 

For  Instance,  I  want  to  know  what  my  target  looks 
like  now,  not  last  week;  where  precisely  it  is  or 
is  expected  to  be,  and  what  tricks  can  be 
expected  in  terms  of  decoys  camouflage,  defenses 
etc . 

Then,  when  planning  my  mission,  I  certainly  like 
support  in  clerical  tasks. 

Let  a  system  calculete  my  fuel  use  for  me,  plot 
my  route,  identify  the  risk  when  engaging  threats 
for  the  tactics  selected,  document  my  planning 
for  me  and  prepare  my  system  data  loader  for  me. 
Let  it  allow  me  to  assess  the  consequences  of  an 
info  update  at  the  end  of  my  planning  process  and 
make  it  possible  to  adapt  the  primary  plan  if 
necessary. 

During  my  mission  I  would  like  my  systems  to  show 
me  the  situation  in  an  easily  understood  manner. 
Show  me  relevant  information  only.  I  could 
Indicate  premlsssion  what  I  consider  relevant  and 
what  not.  It  can  also  show  me  my  own  capebilitiea 
in  relation  to  threats. 

You  will  notice  that  I  stress  the  information 
supply  side,  and  the  improvement  of  the  quality 
of  Information,  to  make  it  directly  accessible 
for  che  pilot,  without  the  need  Co  interpret  raw 
data. 

I  do  not  want  the  system  to  think  for  me,  at 
least  not  in  the  sense  that  it  prescribes  my 
tactical  actions. 

It  can  to  some  extent  think  with  me.  For  example 
to  carry  out  some  casks  that  I  do  not  wish  to  be 
bothered  with;  it  may  monitor  my  other  systems, 
decide  which  ones  do  not  perform  correctly,  re¬ 
configure,  and  Inform  me  of  any  degradation  in 
performance,  not  redundancy. 

Also,  if  I  want  so,  a  system  can  perform  specific 
tasks  for  me,  for  instance  do  my  self -protection, 
activate  and  shut  down  jammers  and  throw  decoys, 
provided  its  operation  is  transparent,  which 
means  that  I  know  what  it  will  be  doing. 

More  in  general,  the  functions  of  systems  that 
support  me  need  to  be  clear.  I  have  to  understand 
what  their  products  mean. 

For  route  planning  I  like  a  system  that  shows  me 
the  known  threat,  and  indicates  what  possibly 
could  be  there  that  is  unknown  at  present. 

I  certainly  do  not  want  a  system  that  calculates 
an  optimum  route  for  me  under  the  erroneous 
assumption  that  the  world  is  known,  with  the 
resulc  that  I  have  to  meander  cowards  my  target 
and  then  run  into  a  few  surprises  all  the  same. 

It  is  imperative  that  mission  control  support  for 
manned  systems  is  designed  in  such  a  manner 
thatit  supports  the  pilot,  or  more  in  general  Che 
operator.  If  he  can  not  maintain  a  clear  image  of 
che  situation,  he  cannot  perform  his  job.  Also, 
if  the  support  systems  do  perform  part  of  his 
primary  job,  he  does  lack  the  freedom  of  control 
he  may  need.  And  if  you  let  the  system  ao  it  all, 
you  do  not  need  a  pilot. 
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III.  MISSION  SUPPORT  SYSTEM  DEVELOPMENT 

The  key  word  above  is  support  to  the  user.  To  be 
able  to  do  this,  the  user  must  be  know.  System 
designers  may  think  they  know  the  user.  Human 
factor  engineers  may  think  they  know  the  user, 
the  user  may  think  he  knows  himself.  They  all  are 
wrong. 

Know  yourself.  Most  people  need  more  then  a 
lifetime  to  do  only  that.  The  user  does  not  know 
what  he  needs  until  he  is  confronted  with  what  he 
thought  he  needed,  and  again  and  again.  For  ail 
the  others  It  is  the  same. 

Recognition  of  this  fact  has  guided  the 
development  of  mission  support  systems  in  the 
Netherlands.  The  mission  preparation  system 
CAMPAL  is  an  example.  The  development  of  this 
system  has  been  gradual.  It  has  been  rebuilt 
three  times,  and  been  evaluated  each  time  at  one 
or  more  operational  squadrons.  Presently  its 
software  is  the  core  of  MSS/C.  where  C  stands  for 
CAMPAL,  which  is  being  developed  for  EPAF  F-16 
users  by  CD.  You  will  be  briefed  later  this  week 
on  this  system. 

A  similar  approach  is  taken  with  the  development 
of  an  Air  Base  Command,  Control  and  Information 
System.  At  present  a  part  of  the  system  is 
operational  on  one  of  our  air  bases,  as  a  stage 
in  its  development.  I  should  mention  in  this 
respect,  that  its  development  is  presently  under 
review,  mainly  because  of  the  recent  geopolitical 
changes.  The  old  concept,  that  most  operations 
would  be  from  the  own  MOB'S,  which  is  one  of  the 
elements  in  the  ABCCIS  design,  seems  to  be  no 
longer  valid  for  the  RNLAF. 

I  will  address  this  point  later. 

IV.  FUTURE  ENVIRONMENTS  FOR  MISSION  SUPPORT 
SYSTEMS 

As  you  all  noticed,  the  world  has  changed.  The  WP 
threat  that  dominated  military  thinking  in  the 
West  has  disappeared.  The  Soviet  threat  has 
changed  in  nature.  In  the  wake  of  the  fall  of  the 
WP  society  new  situations  where  military  actions 
could  be  necessary  emerge.  This  is  affecting 
military  thinking,  concepts  of  operation, 
required  means  and  mission  contents. 

It  also  will  affect  the  requirements  for  systems 
that  support  the  missions. 

I  will  try  to  sketch  the  broad  context. 

The  open  question  is  where,  against  whom,  with 
whom,  and  under  what  rules  the  next  conflict  will 
have  to  be  fought.  It  is  not  only  a  question  of 
how  we  assemble  a  fighting  force,  but  even  more 
so  how  we  realize  the  required  effective  command, 
control  and  Information  supply. 

Whereas  in  the  recent  past  the  dominating  drive 
was  the  threat  from  the  east  with  a  limited 
number  of  possible  scenarios,  present 
developments  show  a  larger  variation  in  these 
scenarios,  which  also  are  less  well  defined.  How 
to  cope  with  that? 

The  buzzword  used  here  is  versatility.  The  terms 
you  encounter  are  immediate  reaction  forces, 
rapid  reaction  forces  and  so  on. 

The  recent  conflict  in  Iraq  is  Just  one  example 
of  such  a  possible  scenario. 


What  did  we  see? 

Advanced  technology  assets  such  as  stealth 
aircraft  were  used  for  initial  strikes  to  gain 
advantage  and  create  air  superiority.  Medium 
range  cruise  missiles  were  used  to  attack  high 
value  fixed  targets,  Lethal  and  functional 
defense  suppression  was  used  successfully  at  a 
large  scale,  and  the  bulk  of  the  airborne  forces 
employed  medium  altitude  tactics.  Low  Level 
tactics  were  employed  mainly  where  the  weapon 
characteristics  dictated  its  use.  We  saw  large 
scale  use  of  precision  guided  weapons,  to  avoid 
unwanted  damage,  and  a  hustle  for  damage 
assessment,  the  latter  even  becoming  some  sort  of 
concern,  since  the  level  of  detail  needed  could 
not  be  achieved  with  long  range  sensors. 

For  this  specific  case  lessons  have  been  learned. 
Viewed  in  the  light  of  the  new  NATO  situation  the 
lessons  seem  to  have  the  following  shape: 

In  the  Gulf  scenario  medium  altitude  operations 
were  predominant.  Does  it  mean  low  level  tactics 
are  out?  Certainly  not.  Still  one  should  be  pre¬ 
pared  to  do  it.  Next  time  the  opponents  defense 
could  be  more  potent,  and  some  time  may  be  needed 
to  clear  the  skies.  The  main  lesson  is  that  if 
you  do  not  need  low  level  tactics,  do  not  use  it. 
Choose  the  one  appropriate  for  the  situation. 

It  means  that  air  crews  and  systems,  including 
mission  control  support  for  manned  airborne 
weapon  systems  should  be  able  to  cope  with  both 
environments . 

The  conflict  also  showed  the  benefit  of  being 
able  to  operate  around  the  clock.  In  the  near 
future  technology  will  enable  operations  at  night 
for  an  even  larger  proportion  of  weapon  systems. 
Again  a  variation  in  operation  that  require 
mission  control  support  systems  to  be  versatile. 

The  one  dominating  aspect  in  the  Gulf  conflict 
has  been  the  ability  to  hit  the  proper  target  and 
probably  even  more  important,  not  to  hit  the 
wrong  target.  This  faculty  is  the  main  factor  in 
securing  political  and  public  support  during  the 
conflict.  Target  identification  power  and  weapon 
delivery  accuracy  are  the  main  ingredients  of  the 
recipe . 


Target  identification  is  not  only  a  matter  of 
separating  the  friend  from  the  foe,  but  even  more 
so  the  Identification  of  the  non-combatant. 
Systems  thus  should  support  positive 
identification  of  friend,  non-combatants  and 
foes . 

It  is  equally  important  in  the  air-to-air  as  In 
the  air-to-ground  situation.  If  you  fail  to 
identify  an  erring  airliner  on  the  wrong  track 
and  you  shoot  it  down,  it  does  not  help  your  own 
mental  state,  nor  the  political  status  of  the 
conflict. 

Inversely,  if  your  system  does  not  allow  positive 
identif icstion,  you  may  not  be  able  to  use  your 
fine  BVR  capability,  and  be  forced  Into  a  more 
risky  short  range  exchange.  If  you  shoot  up  a 
convoy  of  refugees,  instead  of  a  tank  column,  it 
does  not  help  a  lot  to  state  that  those  guys  had 
no  business  there. 

This  is  not  a  new  problem,  it  only  has  become 
even  more  important.  Much  effort  has  been  spent 
over  the  years  to  try  to  improve  the  situation. 
Efforts  vary  from  networked  solutions,  where  an 
overall  picture  is  generated  centrally,  using  and 


Incarpracing  information  from  available  sourcaa, 
and  dlscrlbuclng  the  resulc  by  daca-llnk,  Co  non- 
cooperaclva  cargec  recognlclon  methods  on-board 
weapon  systems . 

There  is  no  siaple  solucion  Co  chis  problea.  All 
available  inforaacion  should  be  combined  in 
assessing  who  is  who.  The  final  seep  scill 
remains  co  be  done  on-board.  Here,  pre-nission 
and  beaaed-up  inforaacion  have  Co  be  combined 
wich  the  information  from  on-board  sensors  co 
make  Che  final  assessaenc.  Truly  a  fine  cask  for 
mission  control  support  svstems. 

The  present  command  and  control  concept  works 
with  specialised  units  chaC  are  tasked  froa  a 
high  level.  Specialisations  include  defense 
suppression,  escorts  for  bombing  missions,  pre- 
strike  recce  and  BDA  recce.  The  operation  as  a 
whole  is  planned  in  a  racher  large  detail, 
resultin'  in  a  massive  flow  of  tasking  orders.  It 
seems  that  certainly  in  transitional  stages,  i.e. 
during  the  build  up  at  the  beginning  of  a  con¬ 
flict,  the  availability  of  these  specialised 
units  is  ac  a  premium,  and  the  coordination 
process  is  cumbersome.  Therefore  the  use  of  so 
called  coaposlte  forces,  where  the  necessary 
support  functions  are  available  under  one 
commander,  at  one  location,  should  be  seriously 
considered. 

Uith  composite  forces.  the  tasking  can  be 
simpler.  Also  an  increased  effectiveness  of  such 
forces  can  be  expected,  since  these  can  easily 
train  together.  But  the  local  effort  in  mission 
planning  and  management  will  increase.  Composite 
force  actions  could  be  regarded  as  super¬ 
missions.  a  fact  that  will  undoubtedly  affect  the 
desirable  supporting  systems  properties. 

Composite  Forces  or  not,  for  many  Air  Forces, 
certainly  for  the  Dutch,  the  old  situation,  where 
the  main  action  was  expected  to  take  place  from 
the  own  MOB's  is  no  longer  valid.  More  likely 
next  actions  will  be  froa  bases  elsewhere,  with 
services  and  command  and  control  provided  by 
others,  together  with  nationals  that  speak  other 
languages,  but  with  whom  you  need  to  cooperate 
and  coordinate.  Thus,  the  preferred  properties  of 
planned  and  already  realised  Infrastructure  on 
the  own  MOB's  related  to  mission  preparation  and 
execution  do  change.  Such  facilities  will  need  to 
be  deployable,  or  be  available  at  the  host  base, 
when  wartime  use  is  envisaged.  The  other  part 
will  have  primarily  a  training  value.  Moreover, 
the  question  what  parts  of  the  command  and 
control  system  needs  to  be  standardized  comes 
into  a  new  light.  At  first  sight,  it  seeas 
appropriate  that  mission  preparation  and  mission 
management  support  systems  will  remain  weapon- 
system  specific  fot  quite  a  long  time  to  come. 
The  main  argument  for  this  is  that  the  weapon- 
systems  themselves  will  be  quite  different. 

These  supporting  systems  thus  have  to  be 
deployable.  For  the  casual  observer,  the  command, 
control  and  information  systems  that  supply  the 
mission  systems  with  tasking  and  information 
could  well  be  standardized.  Meteo  info,  intelli¬ 
gence  info,  tasking  orders,  availability  data 
etc.  do  lend  themselves  to  standardisation  in 
information  contents.  The  process  to  arrive  ac 
technical  and  Information  standards  is  under  way. 
but  by  no  means  completed. 

The  properties  of  mission  control  support  systems 
will  affect  the  standardisation  agreements  that 
are  being  developed.  and  vice  versa.  The 
definition  of  missions,  think  about  the  concept 
of  composite  forces.  will  also  affect  the 
functions  of  these  systems. 


Being  technical  people,  your  main  angle  of 
incidence  this  week  will  be  systems  and  enabling 
technologies . 

You  will  address  methods  to  harness  the  flow  of 
data,  and  transfer  it  into  information.  You  will 
address  methods  to  structure  the  control  process, 
so  that  it  will  be  amenable  to  analysis,  and  you 
will  exchange  information  on  your  experiences 
while  developing  systems. 

The  properties  of  these  systems  and  even  of 
elements  of  these  products  are  closely  related  to 
the  structure  of  the  world  in  which  these  are  to 
be  used.  The  opposite  is  also  true,  this  user 
world  is  affected  to  a  large  extend  by  the 
possibilities  of  technology.  Therefore,  in  my 
opinion  there  is  an  important  contribution  to  be 
made  by  AGARD  in  the  field  of  the  definitions  of 
standards,  both  on  the  technical  and  on  the 
information  level. 

V.  CLOSING  REMARKS 

At  the  end  of  my  address  I  like  to  re -Iterate  the 
three  elements  that  constitute  the  main  body  of 
my  speech,  in  reversed  order. 

In  your  work,  try  to  contribute  to  the  definition 
of  adequate  standardisation  rules,  that  allow  the 
necessary  variety  in  operations  and  in  systems, 
while  stimulating  effectiveness. 

When  considering  mission  control  support  systems, 
allow  for  versatility.  Do  not  assume  fixed 
scenarios.  Make  no  "optimum  solutions’  for  incom¬ 
plete  worlds. 

And  last  but  not  least,  when  designing  for  manned 
systems,  remember  the  pilot.  Think  about  his 
mission  and  about  what  he  really  needs.  Allow  for 
use  of  human  faculties.  Keep  him  informed  and 
keep  him  in  the  loop.  If  not.  make  a  drone. 

As  you  may  have  guessed,  I  think  the  subject  of 
this  symposium  is  highly  relevant.  It  is  good  to 
see  that  so  many  scientists  take  an  interest  in 
it.  Undoubtedly,  the  symposium  will  spur  many 
discussions  on  the  subject  and  thus  stimulate 
your  creativeness  into  new  ideas.  I  wish  you  all 
an  interesting,  pleasant  and  fruitful  week. 
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SUMMARY 

The  Gulf  Air  War  started  for  Royal  Air  Force 
Tornado  GR1  aircraft  with  the  delivery  of  JP  233 
weapons  from  low  level  at  night.  After 
sustaining  unacceptable  losses  at  low  level, 
tactics  changed  to  delivery  of  freefall  1000  lb 
bombs  from  mtdlum  level,  at  first  by  night  and 
then  by  day.  Accuracies,  however,  improved 
dramatically  with  the  arrival  in  theatre  of 
precision  guided  munitions. 

The  paper  will  describe  a  typical  mission  covering 
all  aspects  from  initial  tasking  by  ATO,  through 
mission  planning  and  coordination  with 
Intelligence  input  to  deconfliction  and  mission 
execution.  .  Missions  were  flown  as  co-ordinated 
packages.  Tornado  GRl's  being  supported  by  F15C 
fighter  escorts  with  EW  support  from  FlfG  "Wild 
Weasels"  and  EF111  "Raven"  aircraft.  Mission 
planning  by  the  Royal  Air  Force  was  manpower 
intensive  and  could  have  been  streamlined  with  the 
avallabilty  of  more  automated  systems. 

Several  lessons  were  learned  from  the  conflict, 
which  are  listed  and  discussed  in  the  text. 

1  _ INTRODUCTION 

Thi3  paper  discusses  Interdiction  Mission  Planning 
and  Co-ordination  of  RAF  Tornado  GRls  in  the  Gulf 
during  Operation  Granby/Desert  Storm.  It  will 
cover  the  phases  of  the  air  war,  the  planning  and 
execution  of  a  typical  interdiction  mission  and 
some  of  the  lessons  learned  from  the  operations  in 
the  Gulf.  The  participation  of  the  Tornado 
consisted  of  3  Squadrons  of  GRls,  one  each  at 
Dbahran  and  Tabuk  in  Saudi  Arabia  and  one  at 
Muharaq  in  Bahrain.  There  were  also  a  Flight  of 
GRIAs  in  the  reconnaissance  role  at  Dhahran  and  a 
Flight  of  GRls  in  the  ALARM  role  at  Tabuk.  Later 
in  the  conflict,  a  Flight  of  Tornados  equipped  with 
the  TIALD  pod  also  operated  from  Tabuk. 

2  _ PHASES  OF  THE  AIR  WAR 

The  air  war  can  be  divided  into  It  phases: 

a.  Low  level  attacks  on  eneny  airfields  using  JP 
233  and  lofted  1000  lb  bombs  in  the  airburst  mode 
to  suppress  defences. 

b.  Night  medium  level  1000  lb  bombing. 

c.  Day  medium  level  1000  lb  bombing. 

d.  Precision  bombing  with  laser  designation  by 
day  and  by  night. 

Phase  1  -  Low  Level  Attacks.  From  the  start  of  the 
war  on  17  Jan  91  for  It  nights  Tornado  GRl'o  were 
engaged  in  low  level  attacks  on  enemy  airfields, 
using  JP  233  for  runway  denial  and  lofting  (or 
tossing)  1000  lb  freefall  airburst  bombs  in  an 
effort  to  suppress  airfield  defences.  JP  233  was 
generally  effective,  going  for  angled  croaB-cuts  on 
runways  ana  tnxlways.  However,  the  Iraqi  main 
operating  base3  were  so  large,  with  so  much 
redundancy  of  operating  surface,  that  in  many  crises 


the  best  tactic  was  to  plan  to  cut  off  access  from 
the  HAS  sites  to  the  runways.  Lofting  1000  lb  on 
to  defences  was  not  as<  effective  as  had  been  hope:}, 
as  accuracies  achieved  were  not  good  enough  to 
significantly  reduce  AAA.  In  fact  they  often  had 
a  negative  effect,  being  the  first  weapons  to 
detonate  in- the  target  area,  they  generally  alerted 
the  gunners  on  the  airfield,  who  started  a  AAA 
barrage  before  aircraft  dropping  JP  233  arrived. 
Iraqi  AAA  defences  were  much  heavier  than 
anticipated  and  it  seemed  that  every  man  who  had  a 
gun  had  been  ordered  to  fire  it  into  the  air  as 
soon  as  an  incoming  raid  was  detected.  There 
appeared  to  be  few  problems  with  ammunition  suuply 
and  it  was  quite  literally  like  flying  into  a  wall 
of  lead.  The  bomber  force  was  sustaining 
unacceptable  losses,  which  forced  the  next  phase. 

Phase  2  -  Night  Medium  Level  Attacks.  On  21  Jan, 
after  losing  5  Tornados,  tactlc3  were  changed  to 
night,  medium- level,  freefall  1000  lb  bombing, 
against  the  enemy's  main  airfields,  large 
petro-chemical  plants  and  ammunition  dumps.  By 
this  time  the  enemy' b  Early  Warning  and  defence 
co-ordination  systems  had  been  severely  degraded 
and,  apart  from  some  ineffective  attacks  by 
Mirage  FIs  against  F-llls,  his  fighters  has  shown 
no  real  indications  of  Joining  the  battle. 

However,  there  was  major  concern  about  SAM's  and 
AAA  at  the  chosen  operating  altitude  of  around 
20,000  ft,  which  was  in  the  middle  of  the  threat 
envelopes  for  SAM  2,  3,  6  and  the  Improved  Hawk, 
and  on  the  margins  of  SAM  0  and  Roland.  Although 
only  the  heaviest  calibre  AAA  could  reach  above 
18,000  ft,  several  SAM  concentrations  were 
positioned  to  funnel  aircraft  Into  heavy  calibre 
AAA  "killing  boxes". 

To  counter  the  SAM  threats  ,  the  Tornado  had  a 
comprehensive  self-defence  Electronic  Warfare 
capability.  The  Radar  Warning  Reclever  alerted 
crews  to  the  threat,  the  Skyshadow  Jamming  pod 
possessed  counters  to  many  of  the  SAM  systems  and 
the  B0Z  pod  enabled  crews  to  dispense  chaff  and  IR 
decoy  flares.  In  addition,  the  USAF  had 
concentrated  its  worldwide  SEAD  assets  into  a 
relatively  small  theatre  of  operations  and  support 
from  EF-111  "Ravens",  FUG  "Wild  Weasels"  and  F15-C 
fighter  aircraft  was  always  available.  These 
support  aircraft  were  integrated  with  the  bombers 
to  form  consolidated  packages. 

The  effects  of  the  night  bombing  campaign  were 
difficult  to  assess  since  timely  Bomb  Damage 
Assessments  (BDA)  were  not  easily  available,  unless 
the  target  was  an  oil  refinery  which  tended  to 
flare  magnificently  when  hit. 

Phase  3  -  Day  Medium  Level  Attacks.  By  3  Feb,  it 
was  assessed  that  the  fighter  threat  was  minimal 
and  the  SAM  threat  was  decreasing,  therefore,  a 
switch  was  made  to  daylight  medium  level 
operations.  Using  shallow  dive  attacks  still  from 
medium  level,  the  crews  were  able  to  employ  visual 
bombing  techniques  and  get  ranging  Bensors  like  the 
laser  and  the  ground  mapping  radar  (GMR)  locked  on 
to  targets.  Accuracy  improved  and  specific  targets 
on  airfields,  like  stockpiles  of  munitions,  hangars 
aircraft  In  the  open,  were  attacked. 
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Phase  ■*  -  Laser  Guided  Bombing.  It  was  only  with 
the  introduction  of  laser  designators  into  the 
RAF's  inventory  in  the  Gulf  that  the  accuracy  of 
weapon  delivery  really  improver .  The  Squadrons  at 
Tabuk  dropped  precision  guided  munitions  {PGM) 
designated  by  Tornados  equipped  with  two 
pre-production  Thermal  Imaging  Airborne  Laser 
Designator  (TIALD)  poas  whilst  at  Dhahran  and 
Muharaq  the  Buccaneers  designated  with  the  Pave 
Spike  laser  pods  and  the  GRis  dropped  Pave  Way 
laser  guided  bombs  iLGB).  Row  crews  were  able 
accurately  to  target  bridges  (including  pontoon 
bridges  hastily  erected  to  replace  the  ones  that 
had  already  been  knocked  down),  individual  KASs 
and  runway  intersections.  The  TV  imaging  also 
provided  an  instant  assessment  of  the  results  of 
the  attacks  and  crews  did  not  have  to  return  j 
targets  which  had  already  been  hit. 

3 _ A  TYPICAL  MISSION  PACKAGE 

in  describing  a  typical  mission  package,  one  of  87 
flown  by  GRls  out  of  Dhahran,  the  following  points 
will  be  covered: 

tasking  and  the  intelligence  input,  mission 
planning,  co-ordination  and  deconfliction,  and  the 
final  intelligence  input  before  the  mission  is 
flown. 

The  mission.  No.  0301G,  was  an  6-ship  of  Tornado 
GRls  tasked  against  Ar  Ramadi  Petroleum  Store, 
some  10  miles  to  the  West  of  Baghdad.  Time  on 
Target  {TOT)  was  2300s  on  31  Jan,  so  the  mission 
was  a  night  medium  level  sortie,  each  aircraft 
armed  with  8x1000  lb  freefall  bombs.  Initial 
target  notification  was  by  secure  telephone  and 
fax  from  Joint  Air  Headquarters  at  Riyadh,  about 
36  hours  before  TOT.  Formal  notification  was 
receive.,  with  the  arrival  of  the  Air  Tasking 
Order  (AT0)  at  about  0100s  on  the  day  of  the 
i -tack.  The  AT0  was  the  typical  US  document  of 
pproximately  500  computer-generated  pages,  similar 
those  with  which  RAF  aircrew  who  have  attended 
xercises  like  Red  Flag,  have  become  familiar.  It 
detailed  the  support  pack?;®  for  the  bombers  and 
this  consisted  of  lxF-15C  as  fighter  escorts, 

IxFlG  "Wild  Weasels"  and  2xEF-lll  "Ravens"  as  EW 
support.  In  addition  were  details  of  which  AWACS 
would  provide  airborne  control  and,  equally 
important,  the  air-to-air  refuelling  plan  for  the 
-■aid.  Great  distances  were  involved;  for  this 
sortie,  a  track  distance  of  some  1600  miles  was 
flown,  which  required  the  Tornados  to  tank  both 
outbound  and  inbound. 

Once  the  target  had  been  plotted,  mission  planners 
put  together  an  approximate  route  based  on  the 
tanker  plan  from  the  AT0  and  minimum  risk  routes 
from  the  Airspace  Co-ordination  Order  (AC0).  The 
latest  information  about  SAM,  AAA,  radar  and  Early 
Warning  sites  was  provided  by  intelligence 
specialists.  Planning  was  carried  out  using  the 
Feranti  CPGS  Mk  III  system  which  can  process  flight 
planning  information  but  has  only  a  limited 
ability  to  process  intelligence.  There  was  no 
shortage  of  intelligence  and  an  accurate  picture  of 
threat  locations  was  built  up  and  maintained.  A 
very  close  working  relationship  evolved  between  the 
RAF  and  the  USAF  in  intelligence  matters.  The  RAF 
was  given  access  to  Sentinel  Bite  and  Constant 
Source,  and  crews  were  occasionally  able  to  use 
MSS  II  for  confirming  the  route  and  attack  profiles 
which  offered  the  best  chance  of  success  and  the 
least  danger  from  threats. 

Detailed  planning  of  the  route  and  the  attack  was 
always  carried  out  by  the  aircrew  who  would  be 
flying  the  mission.  However,  assistance  was 


provided  by  the  mission  planning  staff  who 
supplied  fixpoints  and  suitable  offsets  for  radar 
bombing  from  information  available  in  the  fixpoint 
catalogues  and  basic  target  grapnics  produced  by 
the  Joint  Air  Intelligence  Reconnaissance  Centre 
i.JARIC).  If  sufficient  information  was  not 
available,  the  mission  planners  would  mensurate 
new  fixes  and  offsets  by  using  the  Point 
Positioning  System  (PPS)  and  very  accurate 
1:10,000  acetate  over’-. ys  of  the  targets  provided 
by  the  Directorate  of  Military  Survey  at  Feltham, 
West  London.  This  assistance  was  very  labour- 
intensive  and  could  have  been  facilitated  by 
continual  access  to  threat  assessment  systems  such 
as  MSS  II  which  were  available  to  USAF  squadrons. 

The  ATO  deconflicted  targets  in  the  same  area  by 
the  use  of  time  blocks.  Detailed  deconfliction 
and  co-ordination  within  the  package  was  worked  out 
between  the  Package  Commander  and  his  element 
leaders  by  using  the  American  supplied  secure 
telephone  system,  KY  68.  Without  this  common 
system  it  is  doubtful  that  package  co-ordination 
and  integrity  could  have  been  achieved.  Over  to 
the  West  of  Saudi  Arabia,  the  Tabuk  squadrons  got 
most  of  their  package  support  from  the  Red  Sea 
Carrier  Group  (the  USS  Kennedy  and  Saratoga). 
Liaison  with  the  US  Navy  was  difficult  because 
there  was  no  common  secure  voice  system  and  all 
routing  and  timings  had  to  be  passed  to  the  US  Navy 
Liaison  Officer  at  Riyadh,  who  relayed  the 
information  to  the  carriers  over  the  Navy  network, 
a  system  fraught  with  delays  and  scope  for  error. 

Deconfliction  within  the  package  was  generally 
accomplished  by  timing  and  height  senara? ion  as 
shown  in  Fig  1.  As  the  package  flew  North  from  the 
border  at  a  groundspeea  of  **5ukt,  the  weasels  ana 
Ravens  were  about  2  minutes  ahead  of  the  Tornados. 
The  Tornados  were  at  about  22-21*000  ft  with  the 
Ravens  below  them  at  about  20-21000  ft .  The  Weasels 
were  at  25*29000  ft  and  the  fighter  escort  ahead 
and  above  at  about  30,000  ft. 

Throughout  the  ingress,  the  Weasels  acted  as 
forward  observers  and  augmented  the  Tornados ' 

RHWRs  by  calling  any  threats  they  picked  up.  The 
Ravens  provided  continuous  jamming  of  any  threat 
radars.  As  the  formation  crossed  32°30'  North,  two 
of  the  F-15s  peeled  off  to  the  r.orth-east  to  block 
any  fighters  taking  off  from  airfields  around 
Baghdad.  Approaching  the  IP,  the  Weasels  and 
Ravens  accelerated  away  to  set  up  CAPs  15  miles 
West  of  the  target  to  start  "working"  the  target 
area  threats,  with  the  remaining  F-15s  providing 
top-cover.  Shortly  afterwards,  the  Weasels 
claimed  a  HARM  kill  on  a  SA3  site  and  at  the  IP 
they  continued  to  give  the  Tornados  information  on 
s.ireats  still  radiating  in  the  target  urea. 

However,  the  very  presence  of  the  Weasels  and  the 
Ravens  acted  as  a  deterrent  to  the  enemy  defence 
systems.  With  all  the  support  elements  in  place 
as  shown  in  Fig  2,  the  Tornados  flowed  through  the 
target  at  15-20  secs  spacing  on  two  attack  tracks, 
releasing  at  about  **  miles  to  go.  The  last 
aircraft  called  off-target,  allowing  the  package  to 
reform,  climb  and  egress  to  the  Bcuth. 

«11  8  Tornados  released  their  weapons  on  the 
target,  the  crews  reported  seeing  massive 
explosions  and  a  great  deal  of  unair.ed  AAA  coming 
up  to  about  15,000  ft,  which  seemed  to  increase  in 
intensity  as  each  set  of  bombs  impacted.  The 
target  was  left  burning  and  fires  could  still  be 
seen  from  the  air  .“,0  miles  away. 
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k _ LESSONS  LEARNED 

The  package  system  is  the  most  effective  use  of 
limited  assets  and  concentrates  the  available 
forces  in  time  and  space.  For  this  reason,  if  UK 
forces  become  in  any  future  conflict,  it  would  be 
best  to  prosecute  the  war  in  alliance  with  US 
forces.  To  that  end,  the  RAF  should  retain  its 
familiarity  with  US  tactics,  procedures  and  with 
the  ATO  type  of  tasking.  'RAF  participation  in 
exercises  such  as  Red  Hag,  Maple  Flag  and  the 
Composite  Air  Operations  (COMAO)  package  training 
system  used  in  the  Central  Region  should  be 
increased. 

A  common,  secure  communications  system  is  essential 
for  package  planning  and  deconfliction. 

Within  the  RAF,  intelligence  and  mission  planning 
are  manpower  dependant.  More  automated  systems, 
like  the  MSS  II,  which  link  intelligence  and 
planning,  need  to  be  developed.  It  is  understood 
that  Hunting  is  developing  such  a  system. 

Pathfinder  2000,  for  use  with  the  Harrier  GR5/7 
and  the  tactical  transport  fleet.  This  or  a 
similar  automatic  system,  should  be  made  available 
to  the  Tornado  force  so  that  routing,  fixing, 
targetting  and  intelligence  information  can  be 
displayed  and  manipulated  quickly  and  accurately. 

The  complexity  of  modern  weapons  systems  means 
that  future,  operations  will  always  be  mounted  from 
fixed  bases  with  technical  back-up  facilities. 
Therefore,  it  should  be  planned  to  take  advantage 
of  these  facilities  by  using  sophisticated  computer 
systems  to  reduce  the  workload  and  manpower  in  such 
areas  as  mission  planning  and  intelligence 
dissemination. 

Weapons  need  to  be  versatile.  A  weapon  that  can 
only  be  delivered  from  low  level  becomes  so  much 
scrap  metal  when  the  delivery  tactic  changes  to 
medium  level.  The  JP  233  and  the  BL  755  fell  into 
this  category,  leaving  only  the  freefall  1000  lb 
bomb  as  a  viable  weapon  for  the  Tornado. 

Finally,  the  most  important  lesson,  that  tactics 
must  remain  flexible.  Upon  discovering  that  enemy 
airfields  were  heavily  defended  by  AAA,  the 
Tornados  were  forced  to  abandon  low  level  attacks 
and  to  bomb  from  medium  level,  a  role  for  which  the 
RAF  was  totally  unprepared  because  for  25  years  it 
had  been  practising  to  fight  a  low  level  offensive 
air  war.  Medium  level  bombing  proved  to  be  very 
effective  in  this  theatre  when  smart  weapons  were 
eventually  used,  but  it  could  have  been  more 
effective  earlier  had  aircrew  previously  trained 
in  that  environment.  Had  it  been  necessary  and  had 
the  Iraqis  started  using  their  airfields  again, 
there  is  no  doubt  that  the  Tornaaos  would  have 
returned  to  low  level  to  deliver  JP  233.  Delivery 
tactics,  though,  would  have  been  different  from  the 
large  co-ordinated  formation  attacks  originally 
used.  Single  aircraft  or  pairs  flying  through 
simultaneously  at  low  level  and  high  speed  at  night, 
seperated  by  long  and  random  gaps,  would  have 
retained  the  advantage  of  surprise  and  hopefully 
delivered  the  weapons  before  the  AAA  barrage  had 
been  alerted. 

5 _ CONCLUSION 

The  L  phases  of  the  air  war  for  the  Royal  Air  Force 
in  the  Gulf  evolved  through  changing  tactics  in 
response  to  a  changing  threat.  Missions  were 
flown  as  packages,  the  bombers  recievlng  fighter 
and  EW  support  from  the  USAF.  Accurate  and  up  to 
date  Intelligence  information  was  always  availaoie 
from  a  variety  of  sources  and  rr'ssion  co-ordination 
was  simplified  by  the  availability  of  gooc  secure 


telephone  systems.  The  main  lessons  learned  from 
the  conflict  were  as  follows: 

Force  packaging  is  the  most  effective  use  of 
limited  assets  and  should  be  regularly  practised 
by  NATO  aircrews. 

A  common  secure  communications  system  is 
essential  for  package  planning  and  deconfliction. 

The  Tornado  force  should  aquire  an  automatic 
mission  planning  system  capable  of  displaying  the 
latest  intelligence  picture  and  planned  track  in 
order  to  select  the  minimum  risk  route. 

Tactics  should  remain  flexible  and  planners 
must  not  fall  into  the  trap  of  thinking  that  an 
offensive  air  war  can  only  be  fought  from  low 
level  thus  leaving  a  gap  in  our  arsenal  of  medium 
level  munitions .  A  stand-off  runway  and  area 
denial  weapon  should  be  developed  without  delay. 
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1.  SUMMARY 

Airborne  or  Ground-Based  Pilot 
Mission  Planning  is  a  single 
important  link  in  the  chain  of 
activities  that  is  required  to 
facilitate  operating  airpower 
from  an  airbase.  Other  elements 
of  that  chain  include  Target 
Recce  and  Allocation  and  Sortie 
Generation. 

It  turns  out  that  information 
management  problems  associated 
with  intelligence  generation, 
also  apply  to  effectively 
controlling  Sortie  Generation, 
both  to  make  most  efficient  use 
of  scarce  resources  and  to 
generate  an  organisation  that  is 
able  to  benefit  from  Pilot 
Mission  Planning  improvements. 

An  obvious  solution  in  improving 
an  information  management 
problem  is  designing  a  Command, 
Control  Communications  and 
Information  System  (C3IS) .  To 
improve  design  and  development 
of  these  C3I  systems,  it  is 
proposed  to  combine  the  design 
of  those  systems  and  the  use  of 
Battle  Management  Training 
Systems . 

Developing  operational  and 
training  systems  together  has 
possibilities  to  increase  user 
involvement  and  acceptance  and 
incorporate  studies  towards  not 
only  just  fielding  a  C3I  system, 
but  looking  at  the  most 
effective  combination  of  System 
and  Organisation. 


As  a  case  the  design  of  the 
Airbase  Operations  Wargame  for 
the  Royal  Netherlands  Airforce 
is  presented  and  some 
conclusions  are  drawn  regarding 
the  possible  use  of  this  system 
in  designing  C3I  systems  such  as 
the  Airbase  Command  and  Control 
Information  System  ABCCIS. 


2 .  INTRODUCTION 
During  the  last  few  years,  and 
especially  towards  and  during 
the  Gulf-war  a  lot  of  effort  has 
been  directed  towards  Pilot 
Mission  Planning  Tools.  The 
requirements  of  flexible 
response  on  targets  of 
opportunity,  the  incorporation 
of  real  time  intelligence,  the 
mission  packaging  and  a  decrease 
in  available  resources  has  lead 
to  a  requirement,  to  shorten 
Pilot  Mission  Planning  times  and 
to  increase  Mission  Planning 
Quality.  A  number  of  Pilot 
Planning  Tools  have  been 
designed  and  fielded. 

But  Pilot  Mission  Planning  is 
only  a  link  in  the  chain  of 
projecting  Airpower: 

1 .  Target  Recce 

2.  Target  Prioritizing 

3.  Target  Allocation 

4.  Mission  Planning 

5.  Mission  Preparation 

6.  Mission  Launch 

7 .  Mission  Execution 

8.  Mission  Debriefing 
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In  these  steps  a  lot  of  emphasis 
is  placed  on  the  quality  of 
available  information. 

Numerous  studies  have  already 
indicated  an  information  problem 
within  the  intelligence 
community.  The  sheer  size  of  the 
available  intelligence  data 
makes  it  very  difficult  to 
generate  adequate  and  timely 
target/mission  planning 
information.  This  is  being 
addressed  by  trying  to  design 
automated  systems.  Pilot  Mission 
Planning  is  a  part  of  the 
intelligence  and  planning 
process  that  could  be  supported 
by  such  systems. 

However  effective  projection  of 
Airpower  not  only  precludes 
quality  target  information  and 
efficient  use  of  available 
resources,  but  also  an  exact 
knowledge  about  the  status  of 
those  resources. 

Projecting  Military  Force  is  not 
only  being  able  to  generate  that 
force,  but  also  being  able  to 
plan  beforehand  exactly  when  and 
where  that  generation  takes 
place.  That  means  for  airpower 
planning  that  adequate  knowledge 
about  the  Sortie  Generation 
Capabilities  is  needed  to  insure 
that  realistic  tasking  and 
reliable  Times  over  Target  can 
be  realized. 

Sortie  Generation  Capability 
Assessment  is  therefore  of  prime 
importance,  not  only  to  insure 
realistic  allocation  and 
tasking,  but  also  to  make 
efficient  use  of  the  available 
Sortie  Generation  Resources  on 
the  airbases.  Increasing  the 
quality  of  these  assessments  not 
only  increases  the  quality  of 
the  airpower  planning  and  Sortie 
Generation  Control,  but  also  is 
mandatory  to  make  effective  use 
of  Pilot  Mission  Planning  Aids, 
by  increasing  the  effectiveness 
of  the  Sortie  Generation 
organisation. 


Obviously,  increasing  the 
quality  and  speed  of  Pilot 
Mission  Planning  without 
insuring  a  well  run  organisation 
to  perform  preparation  and 
launch  has  no  benefits  for 
Airpower  projection  as  a  whole. 
All  links  in  the  Airpower 
Projection  chain  should  be 
strenghtened  equally. 

In  the  following  chapters  focus 
will  be  placed  on  improving 
Airpower  Planning  Effectiveness 
and  improving  Sortie  Generation 
Capability  Effectiveness. 


3.  INCREASING  AIRPOWER  PLANNING 
EFFECTIVENESS  THROUGH  C3I 
SYSTEMS 

Airpower  planning  is  largely 
dependent  on  the  availability  of 
timely  accurate  information, 
both  on  targets,  current 
situation  and  resource  stati, 
and  tools  or  methodologies  to 
manipulate  this  information  as 
needed  at  will.  Therefore 
Command ,  Contr o 1 ,  Commun icat ions 
and  Information  Systems  (C3IS's) 
are  designed  and  fielded. 

A  large  part  of  the  current  C3I 
system  designs  are  technology 
driven.  Obviously  all  design 
methodologies  that  are  geared  to 
produce  an  accurate,  logical  and 
consistent  system  are  mandatory 
in  designing  these  complex 
systems. 

However,  as  experiences  in  civil 
automation  projects  have  shown, 
a  system  concept  should  not  only 
be  based  on  what  is 
technologically  feasible  or 
desirable  but  should  also  be 
based  on  the  best  way  of 
embedding  technology  in  the 
organisations  that  are  supposed 
to  use  these  systems  in  order  to 
work  more  effectively  [Schulein 
(1),  Borawitz  (4)]. 

This  implies  that  the  way  in 
which  an  organisation  is  going 
to  use  a  C3IS  should  be 
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identified  before  the  system  is 
designed. 

Any  system  that  just  delivers 
data  without  taking  into  account 
the  ways  the  organisation  and 
its  management  processes  are 
structured  is  at  best  a 
Communication  and  Information 
System. 

The  way  an  organisation  is  going 
to  use  a  C3IS  is  dependent  on 
goals,  tasks,  means,  situation, 
procedures,  tradition,  and  worst 
of  all:  people.  To  identify  the 
first  6  items  is  already  a  tough 
problem,  but  to  measure  the 
impact  of  behaviour  of  groups  or 
individuals  is  extremely 
difficult.  A  close  match  between 
the  organisational  behaviour  and 
a  C3IS  is  required  to  gain 
acceptance  and  participation 
from  the  (future)  users.  This 
match  can  only  be  made  by 
looking  at  the  complete  concept 
of  the  C3IS  and  the  organisation 
together. 

The  ability  to  deliver  an 
effective  automated  system 
without  any  organisational 
changes  has  proven  to  be  almost 
impossible  to  date.  So  before  a 
C3IS  is  designed  it  should  be 
quite  clear  in  what  way  the 
target  organisation  and  its 
management  is  going  to  use  or 
misuse  the  system. 

This  is  not  only  mandatory  to  be 
able  to  design  and  field  a 
system  that  will  be  accepted  by 
the  users,  but  also  is  needed  to 
be  able  to  validate  the 
operational  effectiveness  of 
that  C3IS.  As  experiences  in 
both  civil  and  military 
applications  have  shown, 
automating  some  activities  of  an 
organisation  will  not 
automatically  mean  that  the 
effectiveness  or  the  production 
of  that  organisation  (airforces 
and  projecting  airpower)  is 
increased. 


To  involve  (future)  users  in  the 
design  and  development  process  a 
way  should  be  found  to  "let  them 
play”  with  the  concept  of  the 
system  in  a  simple  try-out.  For 
non-technical  users  it  is 
extremely  difficult  to  express 
their  requirements  on  paper  to  a 
computer  expert.  But  most  users 
perfectly  know  what  they  want  or 
like  when  they  have  hands-on 
experience  with  a  model. 

The  solution  for  this  is  hardly 
original:  building  a  prototype 
of  the  system  for  the  user  to 
play  with  is  a  common  solution. 

However,  a  prototype  in 
conventional  means  has  some 
drawbacks.  Often  the  prototype 
is  ill  defined,  almost  trivial 
in  contents  and  even  with  modern 
software  development  techniques 
quite  expensive  to  build.  What 
really  would  be  ideal  to  have  is 
a  testbed  system  that  is  cheap, 
reliable,  especially  build  to  be 
changed  and  redesigned,  with 
sufficient  substance  to  allow 
users  to  "play"  with  it  for  a 
longer  time  without  becoming 
trivial  or  boring. 


4.  INCREASING  SORTIE  GENERATION 
EFFECTIVENESS 


4.1  Activities 

Sortie  generation  activities  can 
be  divided  into  four  categories: 

*  Tasking 

Acquiring  realistic  tasking 
conditions . 

*  Sortie  Generation 
Developing  an  effective 

organisation. 

*  Capability  Assessment  and 
Resource  Management 

Developing  an  effective 
organisation  control. 

*  Pilot  Mission  Planning 
Developing  an  effective 

mission  execution. 

To  increase  the  Sortie 
Generation  effectiveness  of  an 
airbase,  measures  can  be  taken 
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in  each  of  these  four 
categories. 


4.2  Improvement  Measures 

The  improvement  of  all 
categories  is  served  with 
improvement  in  resource 
availability  and  sustainability. 
But  barring  this  a  number  of 
other  measures  could  be  taken. 

To  improve  Tasking  the  following 
solutions  could  be  pursued: 

-  Up  to  date  status  reports 

-  Intelligence  Control  Systems 

-  Resource  Control  Systems 

To  make  Sortie  Generation 
execution  more  efficient  a 
number  of  procedural  or 
organisational  measures  can  be 
taken : 

-  Squadron/Weaponload 
Standardisation 

-  Pre-Planning  and  Pre-Loading 

-  Resources  and  Training 

-  Interoperability 

Elements  of  Capability 
Assessment  and  Resource 
Management  that  could  be 
supported  are: 

-  Assessment 

-  Resource  Control 

-  Response  Times 

-  Reporting. 

And  of  course  the  Pilot  Mission 
Planning  Tools  and  Procedures 
already  mentioned  could  also  be 
applied. 

Physical  measures  concerning 
Sortie  Generation  execution  have 
been  taken  in  the  past  and  are 
still  important.  However  to 
increase  the  effectiveness  of 
the  Sortie  Generation 
Capabilities  the  control  of 
those  activities  is  becoming 
much  more  prominent.  So  what 
activities  can  be  performed  to 
increase  Sortie  Generation 
Management  Effectiveness? 


5.  INCREASING  BATTLE  MANAGEMENT 
EFFECTIVENESS 


5.1  General 

Battle  management  at  airbase 
level  can  be  improved  by 
improving  the  following  basic 
activities: 

*  Base  Capability  Assessment 

*  Sortie  Generation  Assessment 

*  Real  Time  Status  Reporting. 

A  number  of  measures  can  be 
taken  to  increase  the 
performance  of  these  activities: 

*  Standardisation  of 

-  Intelligence  Sources 

-  Reporting 

-  Interoperability 

*  C3I  Systems  for: 

-  Data  Management 

-  Decision  Support 

*  Training  at: 

-  Airbase  management 

-  C3I  system  use 

Basically  two  kinds  of  solutions 
could  be  pursued  to  increase  the 
performance  mentioned: 
incorporate  C3I  systems  at 
airbase  level  and  increase 
Training  of  Management  Personnel 
at  Airbase  level.  Designing  a 
C3I  system  for  an  airbase 
encounters  the  same  problems  as 
presented  in  chapter  4. 

To  increase  training  facilities 
Battle  Management  Training 
Systems  are  needed. 


5.2  Battle  Management  Training 
Systems 

Battle  management  means  the 
complex  integration  of  all 
aspects  of  combat:  intelligence, 
planning,  support,  execution, 
logistics,  command  and  control, 
assessment  and  environment. 

Together  with  the  continuous 
need  to  assess  the  units 
capability  in  order  to  control 
force  planning  and  the 
introduction  of  Command,  Control 
and  Information  Systems  (CCIS) , 
the  working  environment  of 


battle  managers  continues  to 
expand . 

Furthermore  to  introduce  the  new 
tools  and  procedures 
effectively,  it  is  necessary  to 
review  existing  management 
structures  and  to  examine  ways 
to  adapt  these  structures  to 
evolving  requirements.  Due  to 
the  unavailability  of  exercises 
to  look  into  these  problems 
because  of  cost  and  risk, 
training  systems  must  be  used. 

Training  systems  can  be  divided 
in  two  categories.  One  category 
offers  training  opportunities 
that  can  also  be  achieved  by 
other  means  such  as  exercises, 
but  that  can  be  performed  less 
expensive  or  less  dangerous  on 
simulation  systems.  The  other 
category  contains  systems  that 
provide  training  opportunities 
that  cannot  be  achieved  by  any 
other  training  methods  other 
than  actual  combat  operations. 

This  category  contains  Battle 
Management  Training  Systems. 

In  these  "man  in  the  loop" 
systems  not  only  the  handling  of 
complex  situations  is  simulated 
(as  in  wargames)  but  also  tools 
are  offered  to  review  and 
possibly  reorganize  the  way  in 
which  the  management  model  of 
the  game  is  implemented. 

The  use  of  automated  systems  and 
computer  support  turns  out  to  be 
mandatory  for  training  systems 
that  model  an  organization  and 
its  activities  over  time.  To 
model  and  present  an 
organization  and  to  extrapolate 
a  current  situation  into  the 
future  by  relating  the  situation 
to  all  actions  that  have  been 
initiated  by  the  trainees 
requires  the  manipulation  of  a 
huge  amount  of  data.  Real  time 
manipulation  for  training 
purposes  is  beyond  human 
capability  without  computer 
support . 
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So  Battle  Management  Training 
Systems  are  in  essence  highly 
interactive  and  flexible 
computer  simulations. 

Due  to  developments  in  computer 
sciences  in  both  hardware  and 
software  areas  it  became 
feasible  to  build  these  systems. 
The  components  of  such  a  system 
typically  include: 


The  situation  model  describes 
the  actual  system  (for  example 
an  airbase)  that  is  simulated. 

The  gaming  system  has  the  basic 
gaming  structures  that  allow  the 
situation  model  to  be  run  as  an 
interactive  game. 

The  presentation  manager 
generates  the  user  interface  and 
controls  the  information  and 
command  flows  between  the 
players  and  the  gaming  system. 

The  reorganisation  tool  allows 
the  staff  to  change  the 
Presentation  Manager  and  Gaming 
System  in  such  ways  that  other 
management  or  interface 
structures  can  be  tried. 

The  control  tool  allows  the 
staff  to  run  the  simulation. 

In  these  BMTS's  only  one  playing 
team  is  indicated  and  the 
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"enemy"  is  played  by  the 
scenario  and/or  staff.  This  is 
important  to  be  able  to 
precisely  address  management 
problems  or  decision  moments, 
since  in  this  situation  the  flow 
of  the  exercise  can  be  tighter 
controlled  than  in  a  two  sided, 
free  play  game. 

Because  the  system  inherently  is 
built  to  be  changed  and 
redesigned  as  far  as  the 
Presentation  Manager  is 
concerned,  ideas  that  are 
generated  by  the  players  using 
the  system  can  be  readily 
incorporated.  Of  course  changing 
the  presentation  manager  is 
largely  equivalent  with 
redesigning  an  albeit  smaller 
equivalent  of  a  C3I  system!  And 
because  the  Battle  Management 
Training  System  is  not  an  empty 
shell  like  most  Prototyping 
systems,  the  players  cannot  only 
address  presentation  of 
information,  but  also 
availability,  timeliness  and 
operational  impact.  In  this  way 
a  Battle  Management  Training 
System  can  be  used  as  a  testbed 
for  a  future  C3I  system. 


6.  USING  A  TESTBED  C3I/ 
MANAGEMENT  TRAINING  SYSTEM 
Two  applications  of  a  Battle 
Management  Training  System  have 
emerged:  on  one  hand  it  can  be 
used  to  perform  its  primary  goal 
of  providing  Battle  Management 
Training,  on  the  other  hand  it 
can  be  used  as  a  testbed  to 
design  and  develop  C3I  Systems. 

A  number  of  important 
considerations  concerning  the 
use  of  Training  Systems  this  way 
are: 

*  Low  Cost 

Two  demands  of  the  user  can  be 
met  by  most  efficient  use  of 
resources.  The  knowledge  about 
the  situation  at  hand  that  needs 
to  be  acquired  to  successfully 
build  either  a  C3IS  or  a  BMTS  is 
largely  the  same.  The  user 


acceptance  problems  are  largely 
the  same.  Both  from  a  conceptual 
and  a  technical  standpoint 
designing  Battle  Management 
Training  facilities  and  C3I 
Systems  are  largely  equivalent 
(i.e.  application,  design 
methodologies,  technology,  user 
interface,  functionality) 
[Schulein  (2)]. 

*  Judgement  of  effectiveness 
By  intensive  reviewing  in  a 
testbed  environment  more 
information  can  be  gained  about 
the  benefits  of  the  C3I  system 
and  their  operational 
effectiveness.  Be  aware  however 
that  conclusions  drawn  from 
these  Training  Sessions  need  to 
be  interpreted  very  carefully 
before  using  them  in  practice. 

*  User  availability  and 
involvement 

As  has  been  stated  before  the 
design  and  development  for  a  C3I 
system  or  a  Battle  Management 
Training  System  should  include 
not  only  technology  but 
(obviously)  also  organisational 
goals  and  tasks.  Furthermore, 
when  a  support  system  of  any 
kind  is  added  to  an  existing 
organisation  a  reflection  on 
existing  management  structures 
is  advisable. 

It  turns  out  to  be  surprisingly 
difficult  to  express  the  goals, 
tasks,  means  and  procedures  in 
such  a  way  that  this  description 
can  be  used  to  design  systems  to 
improve  operational  and  training 
effectiveness. 

Fortunately,  when  Battle 
Management  Training  is 
introduced  within  the  military 
academies  and  colleges  those 
problems  mentioned  before  are 
exactly  the  subjects  that  are 
addressed  there.  The  officers  in 
the  training  facilities, 
especially  those  facilities  that 
address  management  training  as 
opposed  to  procedural  training, 
are  available  to  rethink  and 
restructure  their  management 
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problems  more  freely  than 
officers  in  operational  service, 
who  are  required  to  run  a 
service. 

These  officers  have  time  to 
think,  therefore  take  them 
seriously,  not  only  in  their 
knowledge  about  the  situation 
but  also  in  their  abilities  to 
review  your  technical  solutions. 

A  bonus  effect  emerges.  Officers 
playing  the  Training  system, 
knowing  beforehand  that  their 
remarks  will  not  only  be  taken 
seriously  in  respect  to  the 
Training  System  itself,  but  also 
will  be  studied  in  respect  of 
their  own  future  C3I  systems, 
will  be  extremely  motivated. 

*  Technical  development 

To  keep  the  Training  system 
manageable  accept  simplification 
in  amount  of  data  or  amount  of 
detail,  but  include  all 
principles  of  datahandling  that 
should  be  present  in  the  C3I 
system.  Otherwise  interpretation 
of  remarks  or  ideas  from 
training  sessions  will  be 
extremely  difficult  to  use  for 
the  real  system. 

Make  a  clean  division  between 
the  components  mentioned  before 
and  aim  for  redesign  of 
Presentation  Manager,  leaving 
the  situation  model  intact. 

Look  further  into  ways  of 
actually  using  the  same  hardware 
and  software  components  for  the 
training  system  and  the  C3I 
system. 

Ensure  that  the  final  C3I  system 
incorporates  a  training  mode 
that  includes  more  than  just 
learning  which  buttons  to  push. 

*  Practice 

To  give  you  some  feeling  about  a 
real  case  the  next  chapter  will 
address  the  Airbase  Operations 
Wargame . 


7  WARTIME  AIRBASE  OPERATIONS: 
THE  AIRBASE  OPERATIONS  WARGAME 


7.1  General 

The  Royal  Netherlands  Airforce 
(RNLAF)  has  designed  a  course 
for  the  RNLAF  Staff  College  to 
facilitate  Battle  Management 
training  for  RNLAF  officers. 
FEL-TNO  was  tasked  to  design  and 
develop  a  training  aid  with  the 
primary  goal  to  address  Battle 
Management  at  airbase  level 


7.2  Characteristics 
The  Battle  Management  Training 
System  that  was  designed,  the 
Airbase  Operations  Wargame 
(AOW) ,  is  in  service  with  the 
Royal  Netherlands  Airforce  Staff 
College,  it  includes  all  aspects 
of  operating  from  a  main 
operating  base:  Air  Operations, 
Sortie  Generation,  Logistics  and 
Support,  Infrastructure,  Passive 
Defence  and  Active  Air/Ground 
Defence  [ Boots  ( 3 ) ] . 

The  system  models  the  airbase 
organisation  below  the  level  of 
the  management  team.  The  users 
of  the  system  play  the  part  of 
management  team  members.  Players 
communicate  with  the  system 
using  the  same  ways  a 
computerized  Battle  Management 
System  would  interact  with  real 
life  management  teams  [Schulein 
(5)]. 

The  AOW-1  Single  Player  system 
is  operational  at  the  RNLAF 
Staff  College.  The  AOW-2  Multi- 
Player  System  is  under 
development  on  a  PC  network  and 
is  scheduled  to  be  completed  in 
1992. 


7.3  Lessons  Learned 

During  the  design  and 
development  of  this  Airbase 
Operations  Wargame  system  the 
Physics  and  Electronics 
Laboratory  was  also  tasked  to 
design  an  Airbase  Command  and 
Control  Information  System 
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(ABCCIS)  for  use  on  the  RNLAF 
airbases. 

These  projects  were  carried  out 
by  two  different  sections  of  the 
laboratory,  that  held  close 
contact  during  the  design  and 
development  of  both  systems. 

Obviously  the  design  for  a 
nation  wide  Airbase  Command  and 
Control  and  Information  System 
like  ABCCIS  is  a  highly  complex 
task.  All  the  same,  from  a  user 
standpoint  only  the  following 
important  differences  exist 
between  the  ABCCIS  system  and 
the  Training  System: 

the  amount  of  data  in  the 
training  system  is  limited? 
the  training  system  will 
interact  with  a  computer 
model  instead  of  a  real 
airbase 

the  training  system  is 
operational  at  the  RNLAF 
Staff  College,  the  ABCCIS 
system  exists  in  the  design 
papers  (status  july  1991) . 

While  using  the  Airbase 
Operations  Wargame  the  officers 
playing  part  in  the  simulation 
management  teams  addressed  a 
number  of  points  concerning 
availability  of  information, 
presentation,  decision  aids  and 
came  up  with  management 
alternatives. 

Because  changes  in  the  training 
system  are  made  fairly  easy  and 
indeed  the  system  is  built  to 
simulate  different  management 
structures,  in  depth  discussions 
about  the  most  feasible 
combination  of  management 
organisation  and  C3I  Systems 
were  stimulated.  The  Airbase 
Operations  Wargame  became  a 
building  box  to  express  new 
ideas  about  Airbase  Management 
and  its  C3IS's. 


8  CONCLUSIONS 

The  following  train  of  thought 
has  prompted  importance  of  using 
Battle  Management  Training 
Systems  as  testbed  systems  for 
Command  Control  Communication 
and  Information  Systems: 
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Building  C3I  and  BMT  systems 
together  is  feasible  but 
requires  precise  definitions  of 
the  application  area  and  the 
goals.  Even  with  precise  goals, 
validation  of  the  system  and 
ranking  of  the  trainees  will  be 
very  difficult  to  quantify  in 
case  of  a  BMTS  and  the  impact  on 
actual  operations  will  be  very 
difficult  to  quantify  in  case  of 
a  C3IS. 


Battle  Management  Training 
Systems  can  be  used  to  play 
testbed  roles  while  examining 
possibilities  of  improving 
Battle  Management  Functions. 
Officers  serving  as  instructor 
or  as  trainee  in  battle 
management  classes  can  be  a 
welcome  source  of  ideas  and 
feedback  concerning  BMTS's  and 
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C3IS's.  Further  research  is 
needed  to  create  concepts  of 
combining  BMTS's  and  C3IS's  into 
the  same  physical  system. 

When  designing  or  developing 
C3IS 's  or  BMTS's,  not  only 
procedural  training  or  decision 
making  should  be  addressed,  but 
alternative  management 
structures  should  also  be 
considered:  the  organisation  and 
its  C3IS  is  a  package  deal. 

The  technological, 
methodological  and  design 
problems  of  BMTS's  and  C3IS's 
turn  out  to  be  equivalent. 
Further  research  should  be 
directed  in  the  direction  of 
developing  methods  to  further 
integrate  those  two  systems,  not 
only  in  design  and  use  but  also 
in  physical  components. 

In  this  way  the  most  economical 
combinations  of  C3IS's  and 
BMTS's  can  be  derived  and  even 
after  fielding  an  integration 
between  operational  use  and 
training  activities  can  be 
maintained: 
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Hiis  paper  illustrates  procedures  and 
techniques  for  automated  target  tracking  and 
location.  A  description  of  the  Mini-KPV  System 
with  target  location  analysis  based  on  error 
propagation  theory  is  given,  while  Video 
Tracker  System  is  discussed. 

Abbreviations 

ADC  Air  Data  Computer 

AG  Antennas  Group 

AHRS  Attitude  and  Beading  Reference  System 

CCS  Comnand  and  Control  System 

CEP  Circular  Error  Probability 

DAAS  Divisicne  Avion! ca  ed  Apparati 

Special!  (Avionics  and  Special  Systems 
Division) 

FtlR  Forward  Looking  Infra  Red  Sensor 

FMS/AP  Flight  Management  System  and  AutoPilot 
FW  Field  of  View 

GCS  Ground  Control  Station 

GPS  Global  Position  System 

LLUV  Low  Light  Level  TV  camera 

LOS  Line  Of  Sight 

LRS  Launch  and  Recovery  Subsystem 

MPES  Mission  Programing  and  Evaluation 

Staticn 

MSC  Mininun  Shift  Keying 

NRPS  Navigation  Receiver  Processing  System 

RPV  Remotely  Piloted  Vehicle 

SKIT  Sistema  di  Rice-Trasnissione  e 

Tracking  (Receive-Transmit  and 
Tracking  System) 

UAV  limanned  Air  Vehicle 

VITC  Video  Telemetry  and  Teleccnmand 

List  of  Synbols 
9  RPV  Pitch  Angle 

$  RPV  Poll  Angle 

<ii  REV  Heading  Angle 

Az  Platform  Azimuth  Angle 

El  Platform  Elevation  Angle 

a*  x  Standard  Deviation 

a  Pan  Angle 


4^  Twist  Angle 

h  RPV  Altitude 

R  Slant  Range 

1.  Introduction 

The  ALOHA  Mini -RPV  System  has  the  capability 
to  perform  different  missions;  one  of  the  most 
useful  missions  is  to  provide  real-time  target 
acquisition  (detection,  recognition, 
identification  and  location)  from  tie 
battlefield.  When  the  target  has  been 
identified  the  Mini-RPV  System  within  the  GCS 
processes  data  arriving  from  the  air  vehicle 
and  with  the  aid  of  digital  terrain  maps  gives 
the  target  location  by  determining  geographical 
coordinates  and  altitude.  Target  location  is 
calculated  using  the  vector  from  the  air 
vehicle  to  the  target  and  the  RPV  present 
position.  The  RPV  to  Target  vector  information 
relative  to  air  vehicle  body  coordinate  is 
derived  from  sensor  LOS  data  acquired  using  a 
stabilized  platform.  This  platform  permits 
target  tracking  irrespective  of  air  vehicle 
motion.  With  present  on-board  electronics  and 
digital  terrain  naps  the  target  location 
accuracy  is  approximately  50  meters  CEP. 

2.  Mini-RPV  System  Description 

The  Mini-RPV  System  has  the  capability  of 
performing  a  wide  range  of  missions.  A  few 
examples  of  the  types  of  missions  that  the 
MIRACH  26  can  perform  are  briefly  outlined 
below. 

Local  reconnaissance,  acquisition  of 
intelligence  data  concerning  the  activities  and 
resources  of  the  enemy. 

Battlefield  surveillance,  systematic 
observation  of  eneny  areas,  places  and 
actvities. 

Target  acquisition,  detection,  recognition, 
identification  and  location  of  targets. 

Artillery  adjustment,  acquisition  of  data  to 
rapidly  and  accurately  engage  selected  targets 


6-2 


with  indirect  fire  weapons. 

Damage  assessment,  acquisition  of  battle  damage 
information. 

The  Mini-RFV  System  (see  fig.l)  comprises  an 
air  vehicle  (MIRACH  26)  with  a  choice  of 
electro-optical  payloads,  a  Ground  Control 
Station  (GCS),  Contend  Control  Station  (CCS) 
plus  Antennas  Group  (AG),  an  anti-j aiming 
datalink,  a  Mission  Programing  and  Evaluation 
Station  (MPES),  a  Launch  and  Recovery  Subsystem 
(LRS)  and  related  Maintenance/Refurbishment 
Subsystem. 

The  air  vehicle  is  the  airborne  platform 
containing  the  mission  payload.  The  air  vehicle 
basic  elements  are  the  air  vehicle  body,  tL,* 
avionics  and  the  payload.  The  air  vehicle  body 
is  partially  built  in  canposice  materials  and 
power  is  provided  by  a  two  stroke  engine 
turning  a  pushing  propeller. 

The  avionics  installed  on-board  (see  fig. 2) 
include  the  Air  Data  Computer  (ADC),  Attitude 
and  heading  Reference  System  (AHRS) ,  Navigation 
Receiver  Processing  System  (NRPS),  Video 
Telemetry  and  I'eleccnmand  (VITC)  and  Flight 
Management  System  and  Autopilot  (FMS/AP). 

T*  e  fMS/AP  performs  the  following  functions  : 
mission  management,  navigation  and  related 
sensors  management,  guidance  and  flight 
control,  payload  conmand  and  control,  data  link 
control  and  flight  plan  management.  The  fMS/AP 
is  produced  by  ALENEA  DAAS  and  is  currently 
undergoing  integration  flight  testing. 

The  complete  avionics  configuration  is  achieved 
with  the  use  of  the  Global  Position  System 
(GPS)  backed  by  the  OMBGA/VLF-Diff. system 
(MIPS).  In  this  configuration  the  navigation 
accuracy  is  better  than  50  m  CEP  within  a 
radius  of  30  km  and  gives  the  option  of 
autonomous  flight.  The  MIRACH  26  has  the 
capability  to  switch  from  remote  control  to 
autonomous  control  and  vice-versa.  Furthermore 
the  RPV  has  the  capability  to  fly  in 
dead-reckoning  navigation  mode  if  both  the 
comnjni cation  and  navigation  radio  link  are 
lost. 

The  on-board  air  vehicle  payload  configuration 
includes  a  stabilized  platform  with  relevant 
electro-optical  sensor  and  a  video  recorder  for 
image  and  data  recording.  As  the  mission 
requires,  it  is  possible  to  install  on  the 
stabilized  platform,  alternatively,  one  of  the 
following  sensors:  High  Resolution  TV  Camera, 
FUR  or  liJ.TV.  The  stabilized  Platform  is  used 


for  stabilizing  the  installed  sensors  both  in 
azimuth  and  elevation  which  involves 
de-coupling  the  optical  axis  with  respect  to 
the  air  vehicle  attitude  and  isolation  from  to 
air  vehicle  vibratior .  Moreover  it  performs  all 
the  plannLg  commands  transmitted  from  the 
grand  operator  or  from  the  video  tracking 
system  and  measures  tjvs  azimuth  and  elevation 
angles  of  the  optical  axis  with  respect  to  a 
reference  frame  fixed  to  the  air  vehicle.  The 
KIFACH  26  is  currently  fitted  with  a  stabilized 
platform  manufactured  by  AUNIA  DAAS. 

The  Conmand  and  Control  Station  is  housed  in  a 
truck  mounted  shelter  and  is  equipped  with  the 
relevant  trolley  mounted  power  generator. 

A  crew  of  three  operators  is  necessary  to 
operate  the  CCS  :  an  air  vehicle  and  antema 
group  operator,  a  payload  operator  and  a 
Station  Contender. 

The  air  vehicle  can  be  launched  and  recovered 
either  under  CCS  or  in  a  completely  automatic 
node.  During  flight,  control  of  the  air  vehicle 
is  possible  in  two  distinct  modes:  autonanus 
control  mode  and  remote  control  mode.  In  the 
autonotnus  control  mode  the  operator  can  change 
both  the  sequence  of  preprogramed  flight  legs 
and  flight  program,  and  resume  the  air  vehicle 
remote  control  to  the  permitted  phases.  In  the 
remote  control  mode  the  operator  can  change  the 
roll/heeding,  the  pitch/altitude  and  the 
throttle/speed. 

Ccnmnication  from  the  CCS  to  the  air  vehicle 
and  vice-versa  is  realised  by  means  of  a  J-band 
anti-jamning  digital  system. 

The  Antennas  Group  is  moulted  on  a  truck 
flatbed  and  is  connected  to  the  CCS  by  a  cable. 
It  can  be  located  far  from  the  CCS  in  order  to 
increase  System  survivability.  It  allows  both 
lift/orientation  of  the  steerable  antenna  and 
air  vehicle  camunication  via  a  radio  link. 

The  Mission  Programing  and  Evaluation  Station 
is  composed  of  an  equipped  truck  mounted 
shelter  and  a  trolley  mounted  power  generator. 
The  station  includes  all  equipment  necessary 
for  planning,  developing  arid  recording  missions 
performed  in  automatic  navigation  mode.  Mission 
flight  path  is  subdivided  into  way  points  for 
each  of  which,  geographical  coordinates,  air 
vehicle  performances  and  payload  ccmnands  are 
defined. 

Evaluation  of  mission  results  can  be  performed 
either  in  real  time,  using  the  continues  flow 
of  information  received  from  the  Conmand  and 
Control  Station,  or  in  play  back.  The 
Evaluation  and  Programing  Station  is  connected 


to  Che  ocher  stations  by  telephone  and  radio 
links. 

The  Launch  and  Recovery  Station  includes  the 
Launch  Station  and  the  Recovery  Substation.  The 
Launch  Station  allows  loading  of  the  air 
vehicle  on  the  launch  ranp  and  connection  of 
the  power  supply  to  the  same  vehicle.  In  this 
phase  the  system  performs  a  pre-flight 
functional  check  of  the  air  vehicle  and  loads 
the  mission  plan.  After  which,  the  system 
ignites  the  take-off  booster  and  launches  the 
air  vehicle. 

Once  landed  the  recovery  sub-station  allows  air 
vehicle  retrieval. 

The  Maintenance  and  Refurbishment  Subsystem 
allows  operational  refurbishment  of  the  whole 
system  up  to  second  level  maintenance. 

3.  Data  link  &  Video- tracker  System 
The  Data  Link  guarantees  a  bidirectional  RF 
time-shared  link  between  air  vehicle  and 
Antennas  Group  while  digital  modulation  of  the 
transmission  data  permits  a  high  degree  of  link 
reliability.  Spread-spectrun  techniques 
(frequency  hopping)  are  implemented  to  secure 
the  conunication  channel.  The  functional 
components  of  the  Data  Link  comprises  on-board 
equipment  (VTTC)  and  AG  installed  equipment 
(SKIT).  Figure  3  shows  the  Data  Link  block 
diagram. 

The  Data  Link  serves  as  a  means  of  data  and 
image  transmission  from  air  vehicle  to  Ground 
Gontrol  Station  (down-link)  and  ccomand 
transmission  from  GCS  to  air  vehicle  (up-link). 

The  VTTC  processes  the  video  signal  receveid 
from  the  electro-optic  sensor  in  order  to 
generate  LOS  pointing  correction  contends 
(Video-Tracking  function)  necessary  to  track 
the  moving  target.  These  cannands  consist  of 
azimuth  and  elevation  rates  used  to  control  the 
stabilized  platform. 

The  video-tracking  function  implemented  is  of  a 
"digital  image  correlation"  type  which 
facilitates  target  tracking  even  in  extremely 
complex  environments. 

Video  signals  transmitted  by  RPV  via  the  radio 
link  are  displayed  on  the  Conmand  and  Gontrol 
Station  monitor.  Target  detection, recognition 
and  identification  is  achieved  by  the  operator 
using  the  video  monitor  and  the  images 
transmitted  from  the  air  vehicle. 

When  the  target  is  identified  the  operator  can 
activate  the  video  tracking  function  by 


transmitting  a  video  tracking  contend  (via  the 
up-link)  to  the  on-board  video  tracker 
equipment. 

At  this  stage  it  is  possible  to  activate  the 
Autotracking  mode.  In  this  mode  the  air  vehicle 
maintains  a  cimilar  path  above  the  target  at 
constant  altitude  and  velocity.  The  circular 
trajectory's  centre  is  the  target  present 
position  while  the  radius  is  equal  to  the  RPV 
altitude.  The  Autotracking  process  generates 
the  cannands  for  the  Autopilot  (Altitude,  Roll 
and  Ground  Speed).  The  Altitude  and  Grand 
Speed  cannands  have  those  values  stored  at 
instant  of  the  Autotracking  mode  insertion 
while  Roll  command  depends  an  Pan  and  Tilt 
values. 

Before  activating  the  video-tracker  function 
the  target  should  lie  within  a  reference  window 
located  at  the  centre  of  the  monitor.  When  the 
video-tracker  function  is  activated  the  image 
in  the  reference  window  is  memorized.  Target 
tracking  is  maintained  by  scanning  the  search 
window  for  an  image  equivalent  to  the  one 
memorized,  (see  figure  4:  Video  Tracking 
Function  block  diagram). 

The  video  tracker  has  the  capability  to  refresh 
the  reference  image  with  the  actual  image 
(update  conmand)  In  order  to  guarantee  target 
tracking,  even  in  the  presence  of  target  shape 
variation  due  to  a  change  in  perspective. 

The  video  tracker  is  able  to  maintain  target 
lock  with  a  variation  of  the  pixel  target 
dimensions,  due  to  a  change  in  FOV  and  air 
vehicle- target  distance,  as  long  as  this 
variation  does  not  exceed  (in  total)  00  X  of 
the  pixel  search  area. 

The  operator  avails  of  a  vernier  to  fine  adjust 
platform  pointing  cannands  generated  by 
video-tracker,  in  this  way,  initial  pointing 
error  or  video-tracker  drift  can  be  nulled.  The 
vernier  commands  are  added  to  the  video-tracker 
corrections. 

The  video  tracker,  comparing  the  actual  image 
with  the  previously  acquired  image,  confutes 
the  different  target  displacements  in  terms  of 
pixels  according  to  the  horizontal  and  vertical 
axes  referenced  at  the  image  center. 

These  displacements  are  converted  to  azimuth 
and  elevation  conmand  rates  used  to  correct  the 
sensor  line  of  sight. 

4.  Target  Location 

Target  location  (the  final  phase  of  target 
acquisition,  after  target  detection, 
recognition  and  identification)  allows  the 
coordinates  (latitude,  longitude,  altitude) 
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determination  of  a  fixed  or  moving  target. 

The  target  location  function  is  computed  (see 
fig.  5)  within  the  OCS  using  the  following 
parameters: 

-  FDV  provided  by  the  electro-optical  sensor 

-  Az,  El  provided  by  the  stabilized  platform 

-  Attitude  and  Heading  ($,  9,  i|»)  provided  by 
on-board  electronics 

-  RPV's  Present  Position  and  Barometric 
altitude  provided  by  on  board  electronics 

-  Eheny  mapped  terrain  provided  by  Counand  & 
Control  Station  data  base. 

The  target's  present  position  is  obtained  from 
the  sun  of  the  RPV's  present  position  and  the 
Target  position  relative  to  RPV  position  (Delta 
North,  Delta  East). 

The  referenced  RPV  altitude,  relative  to 
terrain,  is  calculated  by  means  of  the 
difference  between  the  barometric  pressure 
altitude  and  the  terrain  altitude. 

The  block  diagram  of  figure  5  shows  the 
input/output  of  the  algorithm. 

In  this  way,  by  means  of  a  "Scartometry" 
algorithm,  it  is  possible  to  calculate  the 
target  present  position  in  the  presence  of 
rough  terrain. 

The  "Scartometry"  algorithm  is  based  on  a 
recursive  search  of  the  target's  present 
position  along  the  LOS  vector.  Starting  from 
the  RPV's  present  position  and  coopering  the 
test  points  with  the  terrain  altitude  it  is 
possible  to  obtain  the  target  present  position 
within  a  predefined  error. 

Target  location  algorithm  accuracy  depends  on: 

-  designator  position,  screen  characteristic 
and  sensor's  POV  (target  position  fixing  on 
the  monitor) 

-  RPV's  present  position  accuracy  (for  Lat, 
Long,  altitude  calculation) 

-  on-board  sensor  accuracy  (for  <p,  6,  Az, 

El  calculation) 

-  horizontal  and  vertical  quantization  error  of 
the  mapped  terrain  (for  the  iteration 
algorithm  calculating  target  altitude) 

-  terrain  orography 

In  the  paragraphs  which  follows  target  location 
error  analysis  is  provided  under  the  following 
assumptions : 

-  RPV's  present  position  calculated  by  means  of 
a  GPS  receiver  code  P  altitude  accuracy  32  m 
195X1  [2  dRMS],  latitude  and  longitude 
accuracy  18  m  [952]  [2  dRMS] 

-  target  altitude  accuracy  (mapped  terrain)  12m 

U  o] 


-  error  absence  during  target  designation  on 
the  monitor 

5.  Target  Location  Error  Analysis  Iking  Error 
Propagation  Theory 

5.1  Coordinate  Systae 

The  following  coordinate  systems,  or  frames, 

are  used  to  calculate  the  target's  present 

position. 

Local  Level  frame, 

is  a  right-handed,  orthonormal  coordinate 
system  with  its  origin  located  at  the  RFV's 
centre  of  gravity  and  its  axes  point  true 
north,  east,  and  down. 

The  x  axis  points  north;  the  y  axis  points  east 
and  the  z  axis  points  down  (see  fig.  7). 

RPV  body  frame, 

is  a  right-handed,  orthonormal  coordinate 
system  with  its  origin  fixed  at  the  RPV's 
centre  of  gravity.  The  coordinate  axes  are  also 
fixed  to  the  RPV  and  are  defined  by  the  RPV 
construction  axes.  The  x  axis  points  in  the 
forward  direction,  along  the  RPV  centerline; 
the  y  axis  points  to  the  right  of  the  vehicle 
(along  the  right  wing),  and  the  positive  z  axis 
points  towards  the  base  of  the  vehicle  (see 
fig.  7). 

Line  of  Sight  frame, 

The  Line  of  Sight  frame  is  a  right-handed, 
orthonormal  coordinate  system  with  its  origin 
fixed  at  the  sensor  centre.  The  x  axis  points 
along  the  LOS  from  the  RPV  to  the  Target  and  is 
obtained  by  rotating  the  local  level  frame 
through  an  angle  (^  +  o)  about  the  z  axis 
followed  by  a  rotation  through  an  angle  y  about 
the  y  axis  (see  figures  7  and  8). 

In  the  present  analysis  the  basis  vectors  of 
the  orthonormal  frames  are  indicated  with  xi3 
(see  fig.  6)  where 

x  defines  basis  vectors  of  the  orthonormal 
frames 

i  specifies  the  utilized  frame 
i=0  local  level  frame 
i=3  body  frame 
i=6  line  of  sight  frame 

j  specifies  the  axis 
j»l  x  axis 
j=2  y  axis 
j*3  z  axis 

With  the  above  notations  the  symbol  Ri, 
indicates  the  components  of  the  line-of-sight 
in  the  i  frame,  along  the  j  axis. 
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5.2  Angular  Rotation 

The  angular  rotation  between  the  above  defined 
frames  (see  fig.  6)  produces  the  following 
identity  (Body  to  Line  of  Sight  frame 
transformation  matrix): 

I  ♦]*[  0H  «M  rl-  I  A*  H  Q  ]•[  4k  1 

(5.1) 

Note  that  each  element  of  the  identity  is  a 
rotation  matrix  and  the  identity  does  not 
depend  on  the  angle  4*- 
Using  the  angles  y,  a,  ©,  <j>,  the  rotation 
matrix  becomes: 


X31  ‘ 

^11  ^12  ^13 

*32 

= 

^21  ^22  ^23 

X62 

.X33  . 

■^31  ^32  ^33  ■ 

Lxss 

where  the  elements  are: 

(5.1.  A) 

AjX  «  cosy  cosG  cos  a  +  sin©  siny 

A12  -  -cos©  siny 

A1J  -  siny  cos©  cos  a  -  sin©  cosy 

Aj2  »  cosy  (sin©  sin$  cos  a  +  cost  sine)  + 

-  siny  sin4  cos© 

Aj2  =  -sin©  sin4  sina  +  cos  4  cos  a 

Aj j  -  siny  (sin©  sin$  cosa  +  cost  sina)  + 

+  easy  sint  cos© 

Aj!  *  cosy  (sin©  cast  cosa  -  sint  sina)  + 

-  siny  cost  cos© 

Aj2  »  -sin©  cost  sina  -  sint  cosa 

Aj3  «  siny  (sin©  cost  cosa  -  sint  sina)  + 

+  cosy  cost  cos© 

Using  the  angles  4k*  El,  Az  the  rotation  matrix 
becomes: 


X31 

Bu  B32  B33 

X32 

S 

®21  Bjj  B23 

X«2 

•  *33  ■ 

LB33  B32  B33  J 

■ 

where  the  B4j  elements  are: 

(5.1. B) 

Bu  *  cosAz  cosEl 

B12  =  -sinAz  costt  -  cosAz  sinEl  sintj 
Bn  «  -sinAz  sintj  +  cosAz  sinEl  costj 
B21  =  sinAz  oosEl 

B22  «  cosAz  cos  4k  -  sinAz  sinEl  sin 4k 

Bj3  -  cosAz  sin4k  +  sinAz  sinEl  cos4k 

B31  -  -sinEl 

Bjj  «  -cosEl  sin  4k 

Bjj  -  cosEl  cos 4k 

5.3  Sensor  Line  of  Sight 

The  components  of  the  LOS  vector  (see  fig. 8) 

with  respect  to  the  local  level  axes  (x^)  are: 


Rq!  -  R  COSY  008% 

Roj  -  R  cosy  sin^ 

Roj  =  -R  siny 

where 
%  «  t  +  a 

R01  is  the  IDS  projection  along  the  geographic 
North 

Rg  2  is  the  IDS  projection  along  the  East 
Ro  3  is  the  RPV  altitude  relative  to  the 
terrain 

5.4  Analysis 

5.4.1  Horizontal  IDS  Chapmans  Standard 
Deviation 

The  error  analysis  is  based  on  the  LOS  vector 
variations  8^3,  due  to  6y,  and  81 
variations. 

The  8^3  components  are: 

8*03  ”  ®  cosy  cos%  -  R  siny  cos%  5y  + 

-  R  cosy  simlt  6^ 

«02  -  ®  cosy  sini)t  -  R  siny  sin^  Sy  + 

+  R  cosy  cos4t 
SIq  3  =  -®  siny  -  R  cosy  5y 

After  a  rotation  of  an  angle  4t  about  the  z 
axis  these  variations  become 

81,3  «  ®  cosy  -  R  siny  5y  (5.2) 

®,2  -  R  cosy  (5.3) 

®7j  -  -®  siny  -  R  cosy  Sy  (5.4) 

where  ®,j ,  ®,2  and  are  the  components  of 
IDS  variations  in  the  x,y  and  z  directions 
respectively.  For  clarity  the  components  may  be 
defined  as: 


R\  *  R73  LOS  projection  in  the  vehicle-target 
direction 

R„  =  R,2  IDS  projection  perpendicular  to  R\ 
h  =  Rj3  vehicle  height  over  target 

From  equation  (5.4) 


®  *  -  Sv'siny  -  R  (1/tany)  6y 

Substituting  81  into  (5.2)  and  4$.  *  4/  a  into 
(5.3): 


Su  Sxz  Sl3 

^2  ^23 
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where  the  elements  of  the  sensitivity  matrix 
Sij  axe: 

Su  =  -1  /  tany 

Si  2  “  0 

513  -  -R  /  siny 

514  -  0 

Sji  -  0 
Sj2  -  R  cosy 
Si,  -  0 
S24  -  R 

Assuring  the  vector  elements  [  81  ,  ,  Sy  , 

So-cosy]  as  statistical  independent  gaussian 
variables  and  using  statistical  analysis,  it  is 
possible  to  obtain  a  covariance  matrix  for 
which  the  nondiagonal  elements  are  equal  to 
zero. 

In  this  case  the  standard  deviations  are: 

^  SJn  <?h  +  S213  a2 y  (5.5) 

*  J  S222  S224  0*0. e o«y  (5.6) 

The  variations  &y  and  So  due  to  &0,  &$,  6Az  and 
SI  can  be  obtained  using  the  previously 
defined  identity  (5.1). 


®v  *  ^n®2© +z2l2®14  +z2it^ti 

ffa«co«Y 

Assuring  equal  standard  deviations 

OQ  -  (FIV  Attitude  Accuracy) 

-  cfei  »  OfL7  (Pointing  Angle  Accuracy) 


and  considering 

ZJn+ZJ12  -  1  -  sin2©  sin2  a  <  1 

Z2i3+Z2l4  *  1  -  sin2^  sin2El  <  1 

Z221+Z222  ■  l-(siny  coso  sin©  +  cosy  cos©)2  <  1 
Z223+Z224  -  1  -  cos2*,.  sin2El  <  1 

and  0ff.ce,Y  reduced  to: 


Qy  ^  1  O*  ATT  +  ^PLT  (5*7) 


G&C09Y  —  ^  ^ATT  +  ^PLT  (5-8) 


These  equations  permit  the  evaluation  of  the 
ranrimiw  values  of  ay  and  oa.eear  independent 
of  RPV  attitude  and  Platform  pointing  angles. 

Substituting  (5.7)  and  (5.8)  into  (5.5)  and 
(5.6)  respectivly  it  is  possible  to  obtain  the 
horizontal  LOS  conponents  standard  deviation: 


•  Sy  ' 
.  60*  cosy . 


'Zu  Zl2  Z|J  Z|4  ' 

S©  ' 

■Zn  Zjj  Zj3  Zj4  . 

«♦ 

5Az 

.SI. 

%X  ^  ^  s2ll  +  s2l,  ( 02 ATT  +  °2PLI^  (5-9) 
£  J  S2J2  0^  +  S224  (^ATT  +  (5*10) 

5.4.2  Thrget  Present  Position  Standard 
Deviation 


where  the  elements  of  the  sensitivity 
matrix  are: 


Zii 

Z12 


COSO 

-cos©  sine 


Target  position  is  obtained  by  the  sun  of 
vehicle  present  position  and  relative 
vehicle-target  position.  The  target  present 
position  standard  deviations  are 


Z13  *  -sin©  cos*  sina  -  sin*  cos  a 

Zj_4  =  cos  4,. 

^XRPV  + 

°*rX 

(5.11) 

Zj3  »  sina  siny 

Zj2  -  cos©  siny  cos  a  -  sin©  cosy 

°*yRI>V  + 

^  Hu 

(5.12) 

Zj3  ■  siny  (sin©  cos*  coso  -  sin*  sina)  + 

sin<^ 


+  cosy  cos*  cos© 


where  q,RPV  and  <yRPV  are  the  vehicle  present 
position  standard  deviations. 


Assuring  the  vector  elements  [  60,  6*,  {A z,  SI] 
as  statistical  independent  gaussian  variables 
and  using  statistical  analysis,  it  is  possible 
to  obtain  a  covariance  matrix  for  which  the 
nondiagonal  elements  are  equal  to  zero. 

In  this  case  the  standard  deviations  are: 


6.  Results 

Utilizing  (5.9),  (5.10),  (5.11)  and  (5.12)  is 
possible  to  calculate  the  sensors'  precision. 
Using  the  following  data 
CEP  *  50  m 

Height  *  1500  m 

Slant  Range  =*  2500  m 
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<^RPV  “  VPV  “  <*PV  "  90 

is  possible  to  study  the  correlation  between 

^TT  3n^  *%LI* 

.  9  shews  c^„  vs  cfeLT  for  different  values 
of  . 

Assuring  the  following  accuracies  (1  o)  for  the 
air  vehicle  attitude  and  heading  angles: 
tty  -  14  [mead] 

•  oq  *  7  [mead] 

the  platform  accuracies  become 
<5*  -  «fex  -  6  [mad] 

From  (5.7)  and  (5.8)  the  following  values  of  ay 
and  off.C8lY  are  obtained 

<*-  aa-co»Y  *  9  I®*1] 

Figg.  10  and  11  shew  the  target  CEP  variation 
uider  RFV  present  position  (lat,  Ion,  height) 
variation;  it  is  possible  to  evalutate  the 
Influence  of  the  RFV  present  position 
degradation  on  the  target  position  precision. 
Fig.  10  shows  oy  -  aff.co,Y  vs  on,  for  different 
values  of  CEP. 

Target  CEP  vs  air  vehicle  CEP  for  different 
altitude  standard  deviation  values  are  shewn 
in  Fig.  11. 


reconnaissance.  Upon  definition  of  the  search 
method,  the  system  defines  the  best  IIAV  flight 
path  to  obtain:  a  minimum  flight  time  over  the 
interested  zone,  a  total  area  acquisition  as  a 
function  of  the  optical  sensor  footprint  and 
sufficient  image  recognition  time. 
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Using  the  Monte  Carlo  Method  with  the  same 
input  values  as  above  the  Probabilty 
Distribution  was  obtained  as  a  function  of 
Radial  Error. 


Where  Rad  Err  -  i  err3(>)  +  erri(p) 
and  err(X)  and  err(y)  are  the  errors  on  the 
grand  along  the  target  local  axes  (see  Fig. 
12).  This  Method  estimated  a  CEP  of  47  meters. 
Ihe  comparison  of  the  results  obtained  through 
the  two  methods  is  satisfactory  in  so  far  as 
there  are  no  substantial  differences. 


7.  Conclusions 

Ihe  results  obtained  from  this  analysis 
indicate  that  such  a  target  position  accuracy 
(50  m  CEP  under  conditions  defined  in  para  6) 
is  obtainable  using  commercial  onboard  sensing 
technology  (ASS,  GPS  and  Platform)  and  digital 
mapped  terrain. 

As  regards  target  acquisition  missions, 
automated  target  search  software  is  under 
development  to  maximize  target  acquisition 
probability  hence  reducing  the  operator 
workload.  The  system  provides  a  ground  program 
phase  to  define  the  flight  path  and  area,  line 
or  point  search  routines  to  perform  the 


-  Figure  3  :  Omni  tranadttec/Reoelver  -  0 a  board  Video  Tfeleeetxy  and  Hrln  r—q 

WlnA  fHyi  - 


-  Figure  4:  Video  tracking  function  block  diagram  - 


terrain  napped  data 


Field  of  view  (opt.  sensor) 
RPV  present  position 
RPV  Attitude  &  Heading  (RPV) 


Az,  El  Azimuth,  Elevation  (Stab,  platform) 

Barm.  H  RPV  Barometric  altitude  (RPV) 

PP  target  Target  present  position 


-  Figure  5  :  texget  Location  Function  (in 


&  Central  Station)  - 
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X,.,  LINE  OF  SIGHT  FRAHE 


-  Figure  7:  Reference  Erases  Angular  Rotation  - 


V  V  \ 


V  -  Vehicle 
T  »  Target 
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PREFACE 

Cett*  communication  trait*  da  1' iapact  du  Concept 
da  mobllltd  aur  un  systda*  da  comndaaant  at  da 
contrdl*  da  l'aapaca  adrlan.  La  aujat  aa  llalta  A 
l'dtablissaaent  da  la  aituatlon  adrianna.  Laa 
diffdrents  aspects  nouvaaux  lids  A  la  aobllltA 
sont  abordds  alnsl  qua  las  aoyans  da  rdsoudre 
cett*  dlfflcultd  suppldaantaira  au  nlvaau  da  la 
fusion  des  donndas.  Cas  aoyans  raposant  sur  una 
expdrlenca  original*,  sur  das  rdsultats 
d'expdrlaantation  at  sur  dcs  travaux  d'dtuda.  Da 
futures  evolutions  du  systdas  sont  dgalaaent 
envlsagdes  A  la  fin  (aattant  plus  A  contribution 
las  dldaants  adroportds)  du  papiar. 
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RESUME 

La  naitris*  da  la  situation  adrlanna  ast  un 
aspect  fondaaental  du  thdatre  das  opdrations 
dans  un  conflit  aodarna.  La  plupart  das  systdaas 
da  coaaandeaent  et  da  contrdle,  plus  connus  sous 
la  slgla  C2,  ont  dtd  conqus  pour  manor  das 
opdrations  sur  la  terrltoir*  national,  ou  du 
aoins  dans  la  zona  d'intdrdts  et  da 
rasponsabilitd  d'un  pays. 

L' augmentation  da  la  portde  des  araeaents,  ainsi 
qua  la  diversification  da  la  aenace  ont  contribud 
A  accroltre  considdrablaaent  la  volume  dans 
laqual  la  aaitrisa  da  la  situation  rests  una 
prioritd.  Paralldleaent,  Involution  da  la 
nanaca,  notsaaent  dans  la  doaaina  das  aissilas  A 


long  rayon  d'action  (aissilas  balistiques  ou  da 
crolsidra),  porta  A  envisagar  la  ddplaceaent  das 
centres  da  coaaandaaant  et  da  contrdl*  sur  dcs 
points  avaneds,  das  territoires  alllds,  at/ou  au 
fur  at  A  assure  du  ddplaceaent  daa  zones  da 
conflit,  loin  dcs  installations  fixes  at  das 
aoyans  da  dd tec t ions  sddentalres. 

Cas  donndas  bouseulant  considdrablaaent 
1' architecture  convent ionnella  dcs  systdaas.  Dans 
cat  environnaaent  nouveau,  daa  centra*  aobilca  da 
coaaandaaant  et  da  contrdle  devront  rassaablar 
les  inforaations  de  diverse*  sources  de 
ddtaction,  aobilas  ou  ddplaqables  alias  aussi,  an 
una  reprdsantation  prdcisa  at  coaprdhansive  da  la 
situation  adrianna.  Cett*  aobilitd,  tout  autant 
qua  la  ddforaatlon  du  rdseau  da  sansaurs, 
coaplexifle  les  probldaas  ddjd  noabreux  qua  doll 
rdsoudre  la  poursuita. 

L'exposd  rappclle  qua  la  poursuita  regroup*  las 
aoyans  de  collects,  de  fusion,  de  filtrage  et  de 
syntbdsa  des  inforaations  ddlivrdas  par  les 
sensaurs  dans  la  but  d’dtablir  la  situation 
adrianna.  Ces  inforaations,  obtenuas  avec  la 
coopdratlon  de  la  cibl*  ou  non,  rdsultant  da 
aasuraa  actives  et/ou  passives  ;  alias  peuvant 
contenlr  das  dldaants  d' identification  ou  da 
classification  das  objats  ddtectds.  C'est  grAca  A 
una  connaissance  prdcisa  da  la  situation  adrianna 
renselgnde  (RAP  :  Recognized  Air  Picture)  qua  les 
dlffdrentes  posslbilitds  de  aanoauvres  des 
vdhlcules  adrlens  pourront  etre  gdrdcs, 
contrdldes  et  analysdas.  Des  teebniques 
devaluation  de  la  situation  pourront  alors  dtra 
utlllsdes  A  partir  de  cett*  iaage. 

Outre  las  probldaas  da  transaiasion  des 
inforaations,  qul  peuvant  dtra  traltds  par  des 
aoyans  da  coaaunicatlon  fiablas  at  afficaces  tcls 
qua  les  liaisons  tactlquas  ou  las  systdaas  da 
distribution  das  inforaations  protdgdes  (JTIDS  : 
Join  Tactical  Information  Distribution  Systaa)  la 
gastion  das  inforaations  provanant  d'un  rdsaau 
dvolutlf  pour  la  probldsM  du  aaintian  da  la 
cobdrenca  das  donndas. 

La  sujat  ddvaloppd  dans  cat  axposd  trait*  d'un* 
part  da  systdaas  opdrationnals  coaposd*  da 
sansaurs  fixes  et  rdpartis  et  des  techniques 
alsas  an  oeuvre  pour  fusionnar  las  donndas  da  cas 
sansaurs,  d'autra  part  d'dtudas  sur  las  systdaas 
aobilas  adroportds  cxistants  ou  an  projet.  Ces 
dtudas  da  sensaurs  colocalisds  sur  systdae  mobile 
peraattent  d'envisager  des  solutions  a  base  de 
senseurs  fixes  et/ou  aobiles  rdpartis. 

Les  perforaancas  sont  sadliordas  at  las  ddlais  de 
rdaction  rdduits  par  1*  rdhaussaaant  de  la 
probabilitd  da  ddtaction  aultisanaaur,  la 
vulndrabilitd  du  systda*  ast  abaissd*  at  la 
rdsistanc*  au  brouillag*  accrue  grAca  A  la  prise 
en  coapte  des  assures  aultidlaansionnallas. 

Les  bdndficas  d'un  tal  systda*  aultisanaaur 
parfactionnA  peuvant  dtra  ruinds  par 
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1' Imprecision  de  localisation  et  de 
positionnement  des  divers  senaeurs  qui 
participant  a  l'dlaboration  de  la  situation 
adrienne.  L'effort  particulier  necessaire  a 
1' estimation  continue  des  biais  des  senseurs  et 
egalement  a  la  surveillance  de  la  qualitd  des 
senseurs  est  particulidrement  traitd  dans  cet 
expose. 

[.'optimisation  des  moyens  de  detection 
disponibles  permet  a  la  fois  d'apporter  une 
meilleure  security  aux  senseurs  en  leur  imposant 
des  modes  passifs  plus  discrets  ou  en  commandant 
des  contre-mesures,  et  d'affecter  au  mieux  la 
capacitd  globale  de  detection.  Des  resultats 
d' investigations  expdrimentales  seront  presentds, 
et  plus  particulidrement  la  visualisation  des 
domaines  de  couverture  multisenseur  regroupds 
dans  des  images  synthdtiques  peraettant  aux 
operateurs  du  systems  de  connaitre  a  chaque 
instant  les  possibilitds  de  ddtection  du  systdme 
en  tenant  compte  de  l'environnement  de  chaque 
senseur  et  des  missions  du  systdme. 

En  conclusion,  l'expose  montre  que  les 
investigations  menees  et  les  leqons  apprises 
permet tent  non  seulement  de  ddfinir  1' archi¬ 
tecture  des  futurs  systdmes  multisenseur 
mobiles/ddplaqables,  mais  egalement  de  prdvoir 
quelles  seront  leurs  performances  et  leurs 
capacitds.' 


HOTS-CLES 

Poursuite  Hultisenseur  MST  -  Fusion  de  donnees  - 
HP-VU  -  Gestion  Hultisenseur. 


SOHMAIRE 

L'dtablissement  de  la  situation  adrienne  est  un 
aspect  fondamental  du  thdatre  des  opdratlons  dans 
un  confllt  moderne.  De  plus,  l'augaentation  de  la 
portde  des  armements  ainsi  que  la  diversification 
de  la  menace  contribuent  a  accroitre  considdra- 
blement  le  volume  dans  lequel  la  maitrise  de  la 
situation  reste  une  prioritd.  Ceci  porte  a 
envisager  le  ddplacement  des  centres  de  comman- 
dement  et  de  contrdle  sur  des  points  avancds,  des 
territoires  allids,  et/ou  au  fur  et  d  mesure  des 
zones  de  conflits,  loin  des  installations  fixes 
et  des  moyens  de  ddtections  sedentaires. 

L'exposd  rappelle  que  l'dtablissement  de  la 
situation  adrienne  regroupe  les  moyens  de 
collecte,  de  fusion,  de  filtrage  et  de  synthdse 
des  informations  ddllvrdes  par  les  senseurs,  afin 
de  gdrer,  contrdler  et  analyser  les  diffdrentes 
possibilitds  de  manoeuvre  des  vdhicules  adriens. 

La  mobilltd  du  dispositif  de  surveillance,  tout 
autant  que  les  ddformations  du  rdseau  de  senseurs 
qui  le  composent  rendent  difficile  la  realisation 
de  cette  mission  : 

-  II  faut  connaitre  les  variations  des  recouvre- 
ments  de  couverture  et  s'y  adapter. 

-  II  faut  rapidement  corriger  les  erreurs  de 
calage  entre  les  senseurs. 

-  II  faut  pouvoir  fonctionner  en  envlronnement  de 
fort  brouillage. 

Les  rdalisations  et  investigations  mendes  par 
THOMSON-CSF  sur  le  sujet  permanent  non  seulement 
de  ddfinir  1' architecture  des  futurs  systdmes 


multlsenseurs  moblles/ddplaqables  mais  dgaleaent 
de  prdvoir  quelles  seront  leurs  performances  et 
leurs  capacitds. 


1.  INTRODUCTION 

La  maitrise  de  la  situation  adrienne  est  un 
aspect  fondamental  du  thddtre  des  operations  dans 
un  conflit  moderne.  Une  illustration  de 
1' importance  du  contrdle  des  operations  adriennes 
nous  a,  par  exemple,  ete  recemment  donnee  lors  de 
la  guerre  du  Golfe. 

Cette  maitrise  est  essentielle,  non  seulement 
pour  mener  a  bien  des  actions  offensives,  mais 
egalement  pour  assurer  la  mission  de  defense  d'un 
territoire. 

La  plupart  des  systdmes  de  commandement  et  de 
contrdle,  plus  connus  sous  le  sigle  C2 ,  ont  dtd 
conqus  pour  mener  des  operations  sur  le 
territoire  national,  ou  du  moins,  dans  la  zone 
d'interet  et  de  responsabilitd  d'un  pays.  Le 
ddplacement  de  la  menace  de  conflits  Est-Ouest  en 
tensions  Nord-Sud,  ainsi  que  la  mondialisation 
des  conflits  (on  parle  de  "Nouvel  Ordre  Hondial") 
et  1' extension  des  besoins  de  ddfense  du 
sanctuaire  national  mais  aussi  des  intdrdts 
economiques  en  dehors  des  frontieres,  conduisent 
a  envisager  le  ddplacement  des  centres  de 
commandement  et  de  controle,  (ou  de  parties 
importantes  de  leur  structure)  : 

-  sur  des  points  avancds, 

-  sur  des  territoires  allids, 

-  au  fur  et  d  mesure  du  ddplacement  des  zones  de 
conflits, 

-  loin  des  installations  fixes  et  des  moyens 
sddentalres  de  ddtection  et  de  communication. 

L'augaentation  de  la  portde  des  armements 
(missiles  balistiques,  missiles  de  crolsidre, 
capacitd  de  ravitaillement  en  vol  des  chasseurs), 
la  diversification  des  moyens  mis  en  oeuvre  ainsi 
que  la  gendralisation  des  systdmes  de 
commandement  et  de  coordination  inter-armdes 
contribuent  a  accroitre  considdrablement  le 
volume  dans  lequel  la  maitrise  de  la  situation 
reste  une  prioritd. 


2.  EXPOSE  DU  PROBLEMS 

Dans  cet  environnement  nouveau,  des  centres 
mobiles  de  commandement  et  de  contrdle  devront 
rasseabler  les  informations  des  diverses  sources 
de  ddtection,  mobiles  ou  ddplaqables  elles  aussi, 
dans  le  but  de  produire  une  reprdsentation 
prdcise,  fiable  et  comprdhensive  de  la  situation 
adrienne.  Cette  situation  renseignde  pourra 
ensuite  etre  distribude  aux  diffdrents 
utilisateurs  et  permettre  notamment  le  guidage  et 
le  pilotage  des  engins  adriens  en  mission.  Ainsi, 
la  surveillance  est  d  considdrer  cone  un 
"service"  a  la  disposition  des  autres  fonctions 
d'un  centre  C2 . 

Les  princlpales  missions  de  la  fonction  de 
surveillance  sont  : 

-  la  production  et  l'entretien  de  la  situation 
adrienne  renseignde, 

-  la  gestion  des  moyens  de  surveillance, 


7F-3 


-  la  distribution  de  la  situation  adrienne, 

-  les  echanges  avec  les  autres  systeaes 
(inter-armde) . 

La  fonction  de  surveillance  regroupe  les  aoyens 
de  collecte,  de  fusion,  d' identification  et  de 
synthese  des  informations  delivrees  par  les 
senseurs  (et  autres  systeaes  de  detection)  dans 
le  but  d'etablir  la  situation  adrienne. 

Les  composantes  de  la  surveillance  sont  done  : 

-  les  senseurs  et  moyens  de  ddtection  rattachds, 

-  les  moyens  de  communication, 

-  les  centres  de  fusion  des  donndes. 

Les  informatiens  sur  les  vdhicules  adriens  sont 
obtenues  avec  ou  sans  la  coopdration  des  cibles, 
et  rdsultent  de  mesures  actives  ou  passives.  Ces 
mesures  peuvent  dgaleaent  contenir  des  eldments 
d' identification  ou  de  classification  des  objets 
ddtectds. 

La  mobilitd  du  dispositif  de  surveillance,  tout 
autant  que  les  ddforaations  du  rdseau  de  senseurs 
qui  le  composent,  complexifient  les  probldmes 
ddjd  nombreux  que  la  poursuite  doit  rdsoudre. 

Les  principales  difficultds  lides  a  la  mobilitd 
sont  les  suivantes  : 

-  Impact  au  niveau  des  senseurs  :  les  senseurs 
mobiles  (ou  ddplaqables)  possedent  des 
caractdristlques  moindres  que  leur  version  fixe 
(puissance  d'dmission  et  taille  de  l'antenne 
rdduite,  contraintes  lides  d  la  mobilitd, 
renforcement  des  equlpements  de  structure, 
durcissement  des  cartes  electroniques). 

-  Impact  sur  la  localisation  des  senseurs  :  la 
mobilitd  introduit  une  Incertitude  sur  la 
position  gdographique,  sur  la  vertlealitd  et 
sur  le  calage  au  nord  des  senseurs.  Des  aoyens 
grossiers  de  posit ionneaent  et  de  calage  seront 
gdndralement  utllisds  lorsque  le  temps 
d' Installation  est  rdduit  et  si  la  zone  de 
ddploiement  n'autorise  pas  le  fonctionnement 
optimal  des  moyens  de  localisation  par 
satellite. 

-  Impact  sur  la  transmission  des  donndes  :  le 
volume  des  donndes,  ainsi  que  la  qualitd  et/ou 
la  fiabilitd  des  informations  transaises  par 
les  senseurs  sont  directeaent  corrdlds  au  type 
des  liaisons  utllisdes. 

-  Impact  sur  l'homogdnditd  de  la  situation 
adrienne  le  rdseau  de  senseurs  et  autres 
moyens  de  ddtection  dtant  dvolutif,  la  fusion 
doit  etre  fortement  adaptative  &  ces 
changements. 


3.  BXmiEHCB  TH0H50H-CSF 

TBOMSON-CSF  a  realise  une  poursuite  multisenseur 
basde  sur  une  technique  de  fusion  de  plots  avec 
raise  d  jour  des  pistes  a  intervalles  variables 
(MST/MP-VU).  Cette  technique  offre  de  nombreux 
avantages  naturels,  auxquels  s'ajoutent  des  choix 
industrials  de  conception  et  d'impldaentation  qui 
peraettent  de  rdsoudre  la  major! td  des  probldmes 
dnoneds  dans  la  preaidre  partie  de  cet  exposd. 

Les  probldmes  d  rdsoudre  sont  : 


-  s'adapter  aux  variations  des  recouvremmnts  de 
couverture  et  des  trous  de  ddtection, 

-  corrigcr  rapldement  les  erreurs  de  calage  entre 
les  senseurs, 

-  accepter  des  mesures  de  senseurs  varids 
(prdcislon,  cadence  des  mesures,  modes  de 
fonctionnement,  Informations  aesurdes,  etc), 

-  supporter  les  changements  de  type  de  senseur  et 
du  nombre  de  senseurs, 

_  pouvoir  representer  la  couverture  courante  du 
rdseau  de  senseurs, 

-  fonctlonner  en  environnement  de  fort 
brouillage. 

Les  sections  suivantes  explicitent  la  nature  de 
ces  probldmes  et  les  moyens  de  s'en  affranchir. 

3.1.  Calage  des  senseurs 

Une  condition  prdalable  a  un  pistage  multisenseur 
efficace  est  la  rdsolution  des  probldmes 
d'homogdnditd.  Toute  impldmentation  de  pistage 
multisenseur  avec  une  estimation  mddiocre  des 
biais  des  senseurs  provoquera  1' augmentation  de 
la  taille  des  fendtres  de  corrdlatlon, 
compronettant  ainsi  le  bdndflce  de  leur  rdduction 
obtenue  grace  aux  intervalles  de  temps  courts 
entre  les  nlses  d  jour.  De  plus,  la  prise  en 
compte  d' informations  mutlsenseur  dans  de 
mauvaises  conditions  de  calage  provoquerait  des 
fausses  corrdlations. 

Les  erreurs  sont  provoqudes  par  des  bruits 
systdnatiques  qui  diffdrent  pour  chaque  senseur 
(macro  erreurs).  Ces  "macro  erreurs"  sont  les 
erreurs  de  positlonnenent  des  radars,  les  biais 
en  site,  azinut  ou  distance,  les  erreurs  de 
datation  des  informations  aesurdes,  les  erreurs 
de  squint  ou  de  vertlealitd  du  faisceau 
d'antenne.  De  tels  biais  sont  critiques  dans  une 
poursuite  multisenseur  car  ils  provoquent  des 
oscillations  de  pistes,  accentuees  par  le  faible 
espaceaent  des  mises  a  jour  et  sont  perques  comae 
de  fortes  accdldrations  des  pistes  entre  les 
mises  d  jour. 

Les  "macro  erreurs"  peuvent  changer  brusquement, 
ce  qui  peut  etre  du  d  des  maintenances  techniques 
sur  les  senseurs,  d  1' influence  que  le  vent  a  sur 
la  mdcanique  de  l'antenne  du  senseur  ou  d  un 
mauvais  repositionnement  d'un  senseur  mobile. 
Ceci  impose  une  estimation  dynaaique  de  ces 
"macro  erreurs"  en  utilisant  la  raise  a  jour  des 
pistes. 

C'est  pourquoi  une  fonction  d'estimation  des 
erreurs  systdnatiques  calcule,  en  continu,  les 
erreurs  systdmatiques  par  senseur,  dans  un 
environnement  multisenseur  ayant  un  recouvrement 
sufflsant.  Les  valeurs  calculdes  sont  : 

-  les  erreurs  de  position  des  senseurs  dues  d  un 
mauvais  positlonnenent, 

-  les  biais  en  site  dus  d  un  mauvais  rdglage  du 
site  de  l'antenne, 

-  les  biais  en  azinut  dus  d  un  mauvais  calage  au 
nord  de  l'antenne, 

-  les  biais  en  distance  nesurde  dus  d  un  mauvais 
rdglage  du  Uloadtre  zdro  de  l'antenne. 
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-  les  blais  de  datation  dua  auz  arraura 

systAaatiques  da  datation  daa  plots  (teapa  da 
stockage,  tanpa  da  tranaaiaaion), 

-  lea  arraura  da  dAforaation  du  faiacaau  (squint) 
dues  a  l'extracteur  pour  das  radars  ayant  un 
diagraaaa  d'antanne  dont  le  site  varie  selon 
l'azinut, 

-  les  erreurs  de  vertically  dues  A  la  non 
vertically  de  l'axe  de  rotation  du  senseur. 

Les  biais  de  position  et  de  aesure  des  diffArents 
senseurs  sont  traites  coaae  le  vecteur  d'Atat 
d'un  estiaateur  et  sont  ais  A  jour  cheque  fois 
que  le  senseur  fournit  une  nouvelle  aesure  qui 
correle  avec  une  -des  pistes  selectionnAe.  Four 
optiaiser  le  choix  des  donnAes  utilisees  par  le 
filtre,  une  selection  des  pistes  utiles  est  faite 
pour  ce  filtre.  Ces  pistes  sont  selectionnees 
selon  des  cri tires  tels  qua  le  noabre  de 
senseurs  qui  dAtectent  la  piste  et  la  cinAaatique 
de  cette  piste. 


3.2.  Resistance  au  brouillage 

Les  systAmes  operationnels  bases  sur  la  technique 
HST/MP-VU  incluent  des  capacitAs  de  traiteaent 
des  strobes.  Les  plots  peuvent  avoir  2  ou  3 
dimensions  selon  la  capacity  du  radar,  aais  11 
existe  aussi  des  donnAes  a  1  ou  2  dimensions 
(strobes)  fournies  par  un  radar  (node  ECU) ,  par 
un  senseur  ESH  ou  par  un  senseur  FJL,  lorsqu'une 
cible  coaaence  a  brouiller  ou  Aaettre  un  signal 
radio-ilect rique. 

THOHSON-CSF,  grace  a  son  experience,  est  partisan 
d'une  architecture  nultisanseur  coaprenant  la 
fusion  directe  des  donnAes  provenant  des  senseurs 
actlfs  ou  passifs.  Ceci  est  fondA  sur  : 

-  une  correlation  directe  des  strobes  avec  les 
pistes  existantes, 

-  une  creation  automatique  de  piste  avec  une 
fonction  de  recherche  d' intersection 
vraiseablable  (deghosting)  parmi  les  strobes 
restants  (avec  l'aide  d'un  operateur  pour  cette 
fonction), 

-  un  processus  de  raise  a  jour  utilisant  aussi 
bien  les  plots  que  les  strobes. 

Actuelleraent,  c'est  la  aeilleure  aooroche 

satlsfalsant  les  exigences  suivantes  : 

-  traiteaent  des  donnAes  passives  avec  la 
capacity  de  faire  face  A  un  dAploieaent  r Adult 
de  senseurs, 

-  resistance  contre  le  brouillage  intermittent, 

-  utilisation  du  neilleur  parti  de  cheque 

lnforaation, 

-  charge  de  travail  ainiaisAe  de  1'opArateur  pour 
le  processus  de  fusion, 

-  transition  aisAe  du  pistage  actif  au  pistage 
passif . 

Tout  ceci  est  possible  grice  A  la  capacltA  de 
nettre  A  jour  une  piste  en  utilisant  un  filtre 
coaprenant  une  boucle  de  partage  des  aesures, 
c'est  A  dire  que  contraireaent  A  un  filtre  (ou 
banc  de  filtres)  convent lonnel,  des  aesures 
partlelles  d'aziaut  de  distance  ou  de  site 
peuvent  Atre  introduites  dans  le  filtre. 


Ainsi  THOHSON-CSF  a  rendu  possible  la  aise  A  jour 
autoaatlque  de  pistes  eultisenseur  avec  : 

-  uniquenent  des  plots  "noraaux", 

-  des  plots  "noraaux"  et  des  plots  strobes, 

-  uniquenent  des  plots  strobes. 


3.3.  Gestion  des  senseurs 

L' augmentation  de  la  variAtA  et  des  performances 
de  la  menace  exige  l'adaptation  du  systAae  aux 
contraintes  du  theatre  des  opArations  et 
nAcessite  Sexploitation  optiaale  de  la  dlversitA 
des  senseurs.  Ceci  ne  peut  etre  fait  aanuel- 
leaent,  il  est  done  nAcessaire  d'utillser  une 
fonction  automatique  de  gestion  aultisenseur. 

Cette  fonction  opAre  sur  des  directives 

opArationnelles  coarae  : 

-  aaAliorer  la  surveillance  dans  des  zones 

particulieres, 

-  opArer  en  node  discret  tout  en  conservant  une 
qualitA  satisfaisante  A  la  situation  aArlenne, 

-  augraenter  la  capacitA  de  dAtection  pour  des 
cibles  de  faible  surface  Aquivalente  dans 
certains  couloirs  de  penetration, 

-  suivre  un  plan  de  frequence  particulier  (ce  qui 
peut  conduire  a  n'utlliser  que  certains 
senseurs  ou  a  Araettre  en  node  sectorisA). 

Cependant,  des  deaandes  tres  prioritaires  peuvent 
etre  expriaAes  A  ce  niveau  : 

-  arret  de  l'Araission  ou  Amission  A  faible 
puissance  pour  un  radar  (en  cas  d'attaque  d' ARM 
(Anti  Radar  Missile)  par  exeaple), 

-  avoir  une  cadence  de  nise  A  jour  plus  AlevAe 
pour  certaines  cibles  dAslgnAes. 

Four  reaplir  ce  r61e,  cette  fonction  doit  Avaluer 
la  couverture  aultisenseur.  L'Avaluation  opAre  a 
partir  d' informations  fournies  par  diffArentes 
sources  telles  que  les  donnAes  de  configuration 
gAographique  du  systArae  (terrain,  posit ionnement 
des  senseurs)  ou  les  donnAes  d'environneaent 
fournies  par  les  senseurs  ou  introduites  par 
1'opArateur,  tout  ceci  dans  le  but  d'Avaluer  la 
qualitA  de  la  couverture  aultisenseur  du  systAne 
et  sa  performance  (en  teaps  rAel  ou  en  node  de 
prAdlction). 


3. A.  Avan t ages  de  la  pourauite  MST/MF-Vg 

La  poursuite  MP-VU  industrialisAe  par  THOMSON -CSF 

off re  notaaaent  les  avantages  suivants  : 

-  exploitation  de  la  redondance  de  couverture  par 
l'utilisation  de  toutes  les  aesures  au  fur  et  A 
mesure  de  leur  dAtection, 

-  aaAlioration  des  performances,  notaament 
rAduction  des  durAes  d' initialisation, 
dAtection  rapide  des  Avolutions  des  vAhicules 
aAriens  et  prAcision  accrue  pendant  leurs 
manoeuvres , 

-  raise  A  profit  du  rAhaussenent  de  la  probabilitA 
de  dAtection  par  "l'effet  raultisenseur”, 

-  souplesse  de  la  poursuite  vis-A-vis  de  la 
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diversity  des  inform* t ions  A  fusionner  (plot* 
3D,  2D,  vitess*  radial*,  cad*ne«a  *t  prdcisions 
das  assures  dlf fdrentes) , 

-  resistance  au  brouillage  grace  k  la  possibility 
de  traiteaent  des  assures  partielles  (aisa  k 
jour  des  pistes  avec  les  strobes,  traiteaent 
des  Intersections  de  strobes  aultisenseurs), 

-  surveillance  autoaatlque  des  senaeurs, 

Evaluation  et  correction  des  biais  des  senaeurs 
concurreaaent  k  1' Elaboration  de  la  situation 
adrienne. 

Le  niveau  de  perforaance  atteint  est  confortd  par 
les  rdsultats  obtenus  sur  les  sites  reels  ou 
THOHSON-CSF  a  install*  la  technique  MST/HP-VU.  En 
s'appuyant  d'une  part  sur  cette  experience 
opdratlonnelle  et  d'autre  part  sur  les  etudes  en 
cours,  THOHSON-CSF  envisage  des  solutions  k  base 
de  senseurs  fixes  et/ou  mobiles  repartis. 


4.  BVOmriOHS  POSSIBLES 

Les  vdhicules  aeriens  sont  k  la  fois  les  acteurs 
et  les  aoyens  de  la  surveillance.  Lorsqua  des 
aoyens  de  coasninication  sOrs  et  perforaants 
seront  gdndralisds  k  bord  des  adronafs,  non 
seuleaent  les  vdhicules  adrians  aals  pourront 
participer  d  l'dlaboration  de  la  situation 
adrienne  par  leura  propres  dd tactions,  rendues 
exploi tables  grdee  a  leur  prdcision  de 
localisation  et  d  la  richass*  des  inf oraat ions 
transaises  (Cf.  catalogue  de  aessages  HIDS),  aais 
ils  pourront  recevoir  une  par tie  de  la  situation 
dlabord*  au  sol.  Ainsi,  leur  situation  locale 
sera  enrlchle.  De  plus,  le  prof 11  de  leur  aission 
pourra  dtre  aodlfid  par  la  possibility  de  aettre 
en  oeuvre  leurs  senseurs  actifs  uniqueaent  en 
phase  terainale. 


5.  CONCLUSIONS 

II  rdsult*  que  lorsque  l'on  coapare  les  avantages 
que  procure  une  telle  iapldaentation  de  la 
fonction  de  surveillance  avec  les  probldaas 
spdcifiques  poses  par  la  aobilltd  des  systdaes  de 
surveillance  de  l'espace  adrien,  on  obtient  le 
tableau  suivant  qui  souligne  1' adequation  de  la 
solution  prdconisde  au  problda*  posd  : 


-  H.Carpentler  (1984), 

’Radars,  Bases  Modernes", 

Masson. 

-  B.Roubine,  J-Ch.Boloaey,  S.Drabowltch  and 
C. Ancona  (1978), 

"Antennas" , 

Hasson. 

-  P.  L*  Chevalier  (1989), 

"Principe*  de  Traiteaent  des  Signaux  Radar", 
Hasson. 

-  A. Farina  and  F.A.Studer  (1986), 

"Radar  Data  Processing", 

Research  Studies  Press  LTD. 

-  Dr  J.Lllnaa  and  D.Hall  (1989), 

"Data  Fusion", 

State  of  the  Art  LTD. 

-  S.S.Blackaan  (1986), 

"Multiple-Target  Tracking  with  Radar 
Application", 

Attach  House  INC. 

-  M.Desbols  (1987), 

"Multiple  Radar  Tracking  and  real  tine 
processing", 

Kilcoap'87  in  London  U.R. ,  sep  87. 

-  M.Desbols  (1988), 

"Multi sensor  Tracking", 

Signal  Magazine,  Nov  88. 

-  M.Desbols  (1990), 

"Detection  Beans  management  in  a  aultisensor 
environaent". 

Radar con '90  in  Adelaide  Australia,  Apr  90. 
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ARM  Anti-Radiation  Missile 

C2  Command  &  Control 

ECM  Electronic  Counter-Measure 

ESM  Electronic  Support  Measurement 

MIDS  Multifunction  Information  Distribution 
Systea 

MP-VU  Multiple  Plot-Variable  Update 

KST  MultiSensor  Tracking 

PJL  Passive  Jaaaer  Locator. 


Senseurs  Boins  perforaants 
A 

I 

V 

-  Exploitation  de  "l'effet  multisenseur",  intd 
gratlon  de  senseurs  varids  et  notaaaent 
adroportds  (plus  rapprochds) 


Localisation  peu  prdcis* 

A 

I 

V 

-  Estiaation  autoaatlque  des  biais 

-  Coablnaison  avec  les  systdaes  d*  communication/ 
localisation  adroportds 


Variation  du  rdseau  d*  senseurs 
(en  noabre  et  en  gdoadtrie) 

A 

I 

V 

-  MP-VU  -  aonosenseur  k  cheque  instant 

-  Optlaisation  du  rdseau  d*  ddtectlon 
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PREFACE 

This  papar  appliaa  to  tha  lapaet  of  tha  aobillty 
concapt  on  a  Air  Co Band  &  control  system.  The 
subject  is  Halted  to  the  air  picture 
establishaant.  Various  aspects  linked  with 
nobility  are  pointed  out  as  well  as  solutions  to 
handle  the  additional  difficulty  at  the  data 
fusion  level.  These  solutions  are  based  on  an 
original  experience,  on  experlaent  resultts,  and 
on  study  vork.  Advanced  systea  capabilities  vhlch 
make  aore  Intensive  use  of  airborne  platforms, 
are  also  discussed  at  the  end  of  the  paper. 


TABLE  OF  CONTENTS 


PREFACE 

(TABLE  OF  CONTENTS) 

RESUME 
KEY  VORDS 
SUMMARY 

1.  INTRODUCTION 

2.  PURPOSE 

3.  THOMSON-CSF  EXPERIENCE 

3.1.  Systematic  Error  Assessment 

3.2.  Operation  in  jamming  condition 

3.3.  Sensor  management 

3.4.  HST/MP-VU  advantages 

4.  POSSIBLES  EVOLUTIONS 

5.  CONCLUSION 
REFERENCES 
SYMBOLS  &  ACRONYMS 


RESUME 

Keeping  control  of  the  air  situation  is  a 
fundamental  element  in  managing  the  theatre  of 
operations  in  modern  conflicts.  Most  of  the 
command  and  control  systems,  veil  known  under  the 
C2  acromyn,  have  been  designed  to  carry  on 
operations  on  national  territory,  or  at  least  in 
a  country's  area  of  Interest  or  responsibility. 

Tha  Increase  in  the  arms  range  of  efficiency  as 
veil  as  in  tha  variety  of  the  threat  enlarge  the 
volume  in  which  having  air  control  is  a  top 
priority.  Concurrently,  the  development  of 
weapons,  mainly  long  range  missiles  (cruise 
missiles  and  balletic  missiles),  leads  us  to 
envisage  the  possibility  of  moving  forvard  the 
command  and  control  centres  to  advanced  posts  or 
allied  countries,  or  of  having  then  follov  the 
conflict  area,  far  from  fixed  groundbased 
facilities  and  sedentary  detection  means)  all 
this  contributes  to  rethinking  of  conventional 
system  designs. 


In  this  nev  environment,  mobile  command  and 
control  centres  vlll  have  to  gather  sensor  data 
from  removeable  and  mobile  detection  means,  and 
to  produce  an  accurate  and  understandable  air 
situation.  Sensor  mobility  and  dramatic  shape 
changes  in  sensor  netvorks  both  make  fusion 
process  issues  more  complicated. 

This  paper  points  out  that  multisensor  tracking 
includes  sensor  data  collection,  plot  fusion, 
smoothing  and  synthesis  of  measures  delivered  by 
the  sensor  network,  in  order  to  assess  the  air 
picture.  Target  information  is  obtained  with  or 
vithout  cooperation  of  the  aircraft,  and  results 
from  active  or  passive  neasures)  it  can  include 
identification  data,  and  classification  of  the 
target.  A  precise  RAP  (Recognised  Air  Picture) 
allovs  ‘support  of  air  vehicle  mission  control  and 
management.  Then,  situation  evaluation  techniques 
can  be  applied  on  such  an  accurate  air  picture. 

As  veil  as  information  exchange,  which  can  be 
supported  by  the  means  of  reliable  and  efficient 
systems  such  as  tactical  links  or  joint  tactical 
information  distribution  systems,  tha  management 
of  data  from  a  moving  sensor  network  is 
complicated  by  the  issue  of  preserving 
multisensor  data  consistency. 

This  paper  will  points  out  on  one  hand 
operational  systems  based  on  fixed,  groundbased 
and  distributed  sensors,  vlth  associated 
techniques  perform  tha  fusion  of  data  provided  by 
such  a  sensor  network.  On  the  other  hand,  studies 
about  mobile  airborne/on  board  existing  or 
planned  systems  will  be  shown:  these  systems  are 
mainly  built  out  of  colocated  sensors.  Lessons 
learned  from  both  types  of  systems  allov  us  to 
investigate  solutions  based  on  fixed  and  mobiles 
distributed  sensors. 

Raising  multisensor  target  detection  probability 
improves  tracking  performance  and  reduces 
reaction  time,  vhile  multldimentional  measurement 
processing  reduces  systea  vulnerability  and 
enhances  resistance  to  jamming. 

All  ensuing  benefits  of  such  an  improved 
aultlsensor  system  might  be  shattered  by 
inaccuracies  in  the  positlonnlng  and  alignment  of 
the  sensors  vhlch  contribute  to  the  air  picture 
assessment.  This  paper  vlll  pinpoint  the  specific 
effort  required  for  on-line  sensor  bias 
estimation  and  for  sensor  data  quality 
supervision. 

Optimisation  of  available  detection  means  ensure 
both  sensor  safety  (by  forcing  more  discreet 
detection  modes  and  electronic  counter-counter 
measures)  and  global  surveillance  distribution  to 
allocated  sensors.  Results  from  experimental 
investigations  will  be  shovn,  among  vhlch 
pictures  of  aultlsensor  coverage  reproducing 
synthetised  graphical  images  displayed  to  systea 
users;  these  images  present  in  real-time  the 
systea  detection  capabilities  taking  into  account 
the  sensor  environment  and  surveillance  missions. 

In  conclusion,  this  paper  shows  that  investi¬ 
gations  and  lessons  learned  enables  us  to  stretch 


7E-2 


out  the  desing  of  a  future  mobile/removeable 
multisensor  system  design  as  veil  as  to  estimate 
its  performance  and  capabilities. 


KET-UOBPS 

Hultisensor  tracking  -  MST  -  Data  Fusion  - 
Multiple  Plot  -  Variable  Update  -  HP-VU  - 
Multisensor  Management. 


SUMMARY 

Air  situation  establishment  is  a  fundamental 
element  in  managing  the  theatre  of  operation  in 
modern  conflicts.  Add  to  this  point,  the  increase 
in  the  range  of  efficiency  of  weapons  as  veil  as 
in  the  variety  of  the  threat  enlarge  the  volume 
in  vhich  having  air  control  is  a  top  priority. 
This  leads  us  to  envisage  the  possibility  of 
moving  forvard  the  command  and  control  centres  to 
advanced  posts,  or  allied  countries,  or  of  having 
them  follov  the  conflict  area,  far  from  fixed 
groundbased  facilities  and  sedentary  detection 
means. 

This  paper  point  out  that  air  situation  establis¬ 
hment  includes  sensor  data  collection,  plot 
fusion,  smoothing  and  synthesis  of  measures 
delivered  by  the  sensor  netvork  in  order  to 
manage,  control  and  analyse  the  manoeuver 
possibilities  of  air  vehicles.  Sensor  and  fusion 
centres  mobility  combined  vith  dramatic  shape 
changes  in  sensor  netvork  both  make  the  fusion 
process  issues  more  complicated  : 

-  It  must  have  the  capability  to  accept  changes 
in  detection  coverage  and  manage  them. 

-  It  must  have  the  capability  to  compute  and 
correct  quickly  sensor  alignment  errors. 

-  It  must  have  the  capability  to  process  data 
obtained  in  jamming  conditions. 

Operational  realisations  done  by  TBOMSON-CSF 
enable  us  to  stretch  out  the  design  of  a  future 
mobile/reaovable  multisensor  system  as  veil  as  to 
estimate  its  performance  and  capabilities. 


1.  INTRODUCTION 

Keeping  control  of  the  air  situation  is  a  funda¬ 
mental  element  in  managing  the  theatre  of 
operations  in  modern  conflicts.  The  recent  var  in 
the  Golf  illustres  very  veil  the  high  priority  of 
air  operation  control. 

The  master  is  essential  no  only  for  offensive 
missions  but  also  to  provide  ovn  territory 
defense. 

Most  of  the  command  and  control  systems,  veil 
knovn  under  the  C*  acronym,  have  been  designed  to 
carry  on  operations  on  national  territories,  or 
at  least  in  country's  areas  of  interest  or  areas 
of  responsibility.  Changes  in  threat  for 
East-Vest  to  North-South  conflicts  as  veil  as 
"internationalization"  of  crisis  and  extension  of 
the  defense  requirements  out  of  the  national 
boundaries  to  save  economical  alliances  both  lead 
to  think  about  mobile  command  and  control  centres 
(or  at  least  part  of  C1  centres).  These  centres 
vould  move  : 

-  on  advanced  posts, 

-  on  allied  countries, 

-  close  to  the  forvard  edge  of  the  battle  areas. 


-  far  from  fixed  facilities  and  sedentary  detec¬ 
tion  and  communication  means. 

Several  items  contribute  to  enlarge  the  volume  in 
vhich  having  air  control  is  a  top  priority.  These 
are  : 

-  the  increase  in  range  of  efficiency  of  modern 
weapons  (i.e.  balistic  missiles,  cruise 
missiles  in  flight,  fighter  re-fueling,  ...), 

-  the  use  of  a  large  variety  of  sensor, 

-  the  cooperation  and  data  exchange  betveen 
command  and  control  systems. 


2.  PURPOSE 

In  this  nev  environment,  mobile  command  and 
control  sys teas/centres  vill  have  to  gather 
sensor  data  from  removeable  and  mobile  detection 
means  in  order  to  produce  an  accurate  and 
understandable  air  situation.  Than,  the 
recognized  air  picture  vill  be  disseminated  to 
the  users  to  support  air  vehicle  guidance  and  air 
missions.  So,  the  surveillance  is  to  be 
considered  as  a  "service*  providing  data  to  the 
other  command  and  control  functions. 

Main  tasks  of  the  surveillance  function  are  : 

-  produce  and  maintain  the  recognized  air 
picture, 

-  manage  dedicated  surveillance  means, 

-  surveillance  data  exchange  and  dissemination. 

This  points  out  that  multisensor  data  fusion 
embraces  sensor  data  collection,  plot  fusion, 
smoothing,  identification  and  synthesis  of 
measures  delivered  by  the  sensor  netvork  and 
other  detection  subsystems  in  order  to  assess  the 
air  picture.  Main  components  of  the  surveillance 
are  : 

-  sensors  and  dedicated  detection  sub-systems, 

-  communication  means, 

-  data  fusion  centres. 

Target  information  is  obtained  vith  or  vithout 
cooperation  of  the  air  vehicle,  and  result  from 
active  or  passive  measures  ;  it  can  Include 
identification  data  and  classification  of  the 
target. 

Sensors  and  fusion  centres  nobility  combined  vith 
dramatic  shape  changes  in  sensor  netvork  both 
make  the  fusion  process  issues  more  complicated. 
The  most  important  concerns  due  to  mobility  are 
the  folloving  : 

-  Sensor  concerns  mobile  or  transportable 
sensors  generally  have  a  lover  capability  and 
performance  than  groundbased  series  (lover 
transmissions  pover,  smaller  antenna  size, 
design  adapted  to  nobility,  reinforced  hardvare 
and  electronics). 

-  Alignment  concerns  :  nobility  introduces 
unaccuracy  on  sensor  location  and  on 
verticallty  and  north  alignment.  Trivial  means 
vill  be  commonly  used  to  set  up  sensors  and  to 
align  then  on  site  vhen  the  operating  area  is 
out  of  the  coverage  of  more  accurate 
localisation  system  such  as  satellites  (global 
positioning  system  for  instance). 

-  Communication  concerns  :  data  exchange  capa- 


7E-3 


blllty  and  data  quality  and  raliablllty  arc 
aainly  in  correlation  with  the  data  links.  Due 
to  nobility  constraints  (but  also  jamming 
conditions),  rata  and  characteristics  of 
sansora  data  links  say  be  of  low  fidelity. 

-  Concern  on  the  air  picture  consistency  :  the 
data  fusion  systaas  will  have  to  handle  saooth 
changes  in  sensors  number  and  positions. 


3.  THOMSON-CSF  KPHUgHCK 

THOMSON-CSF  has  completed  a  nultisensor  tracker 
based  on  the  Multiple  Plot  Variable  Update 
technique  (MST/MP-VU).  This  technique  embraces 
numerous  advantages  due  to  direct  plot/strobe 
processing.  Industrial  choices  and  company  design 
for  on-site  implementation  and  system  integration 
allov  this  product  to  solve  a  large  amount  of 
concerns  here  above  described  in  this  paper. 

The  problems  to  solve  are  : 

-  capability  to  accept  changes  in  detection 
coverage  and  to  manage  gaps  in  the  coverage, 

-  ability  to  compute  and  correct  on-line  sensor 
parameters  (i.e.  biases  and  misalignment), 

-  design  to  fuse  data  from  a  broad  range  of 
sensor  types  vhich  have  different 
characteristics  (measures  accuracy,  vorklng 
modes,  number  and  type  of  reported  data,  ...), 

-  display  of  the  current  nultisensor  coverage  as 
a  sensor  performance, 

-  capability  to  process  data  obtained  in  jamming 
condition. 

The  following  sections  describe  the  nature  of 
these  concerns  and  the  way  to  solve  than. 


3.1.  Systematic  error 


A  prerequisite  for  efficient  nultisensor  tracker 
is  to  handle  the  registration  problem.  Any 
attempts  to  implement  a  nultisensor  tracker  with 
poor  sensor  bias  estimation  will  result  in  an 
augmentation  of  correlation  gate  sizes  vhich  vill 
jeopardize  benefits  in  their  reduction  achieved 
by  small  time  Intervals  between  updates. 
Furthermore,  the  adding  of  a  considerable  amount 
of  information  under  such  conditions  might  result 
in  a  number  of  improper  correlations. 


Errors  are  due  to  the  systematic  errors  that 
differ  for  each  sensor  (macro  type  errors).  The 
macro  type  errors  are  radar  location  error, 
elevation  bias,  azimuth  bias,  range  bias, 
time-stamping  errors,  squint  errors  and 
vertlcallty  errors.  Such  biases  are  especially 
critical  in  nultisensor  tracking,  since  they 
cause  different  track  trajectories  swings  that 
are  accentuated  by  a  small  spacing  of  track 
updates  and  appear  as  if  the  track  vas  pulling 
very  high  acceleration  between  updates. 


Macro  errors  may  change  abruptly  in  tine  due  to 
technical  maintenance,  due  to  the  Influence  a 
changing  vind  direction  has  upon  mechanics  of  a 
radar  antenna  and  due  to  vrong  relocation  of  a 
mobile  radar.  This  requires  dynamic  estimation  of 
these  macro  errors,  on-line  vlth  the  maintenance 
of  tracks. 


Then  the  systematic  radar  error  assessment 
estimates  on-line  in  a  multiradar  environment 
vith  sufficient  radar  overlap  the  systematic 
errors  per  radar  : 


-  radar  location  errors,  due  to  vrong  location  of 
the  radar, 

-  elevation  bias,  due  to  vrong  elevation 
adjustment  of  the  antenna, 

-  azimuth  bias,  due  to  vrong  north  adjustment  of 
the  antenna, 

-  range  bias,  due  to  wrong  zero  kilometer 
adjustment  of.  the  radar, 

-  tine-stamping  bias,  due  to  systematic  errors  of 
the  plot  time-stamping  (time  in  storage, 
transmission  time), 

-  squint,  due  to  plot  extraction  for  radars  vlth 
antenna  diagram  tilted  vlth  squint  angle, 

-  radar  verticality,  due  to  unverticality  of 
radar  rotation  axe. 

Position  and  attitude  bias  of  different  sensors 
are  treated  as  state  vectors  of  an  estimator  and 
are  updated  each  time  the  sensor  reports  a  new 
measurement  vhich  correlates  vith  one  of  the 
selected  tracks.  To  optimize  the  choice  of  the 
data  used  by  the  filter,  a  selection  of  tracks 
useful  for  the  filter  is  made.  This  selection  is 
based  on  criteria  like  the  number  of  radars  which 
detacts  the  track  and  the  kinematic  of  the  track. 


ationinJa 


Condition 


Fielded  systems  based  on  the  MP-VU  technique 
Include  a  strobe  processing  capability.  Plots 
from  detection  sources  nay  have  tvo  or  three 
dimensions  according  to  the .  radar  sensing 
capacity,  but  there  are  also  one  -  or  tvo 
dimensional  data  (strobes)  delivered  by  the  radar 
(BCM  node),  by  an  BSM  sensor,  or  by  a  passive 
jammer  locater  sensor,  when  a  target  starts  to 
jam  or  emit  signals. 

THOMSON-CSF,  based  on  its  experiences,  advocates 
a  nultisensor  architecture  with  fusion  of  active 
and  passive  data.  It  is  based  on  : 

-  a  direct  correlation  of  strobes  vith  existing 
tracks, 

-  a  track  initiation  vith  a  deghostlng  function 
on  residual  strobes  (vith  an  operator  help  ft>r 
this  process), 

-  a  track  updating  process  using  either  the  plots 
or  strobes. 

Actually,  this  is  the  best  possible  approach 
satisfying  the  folloving  requirements  : 

-  passive  data  process  able  to  cope  vith  a 
reduced  sensor  deployment, 

-  resistant  against  blink  jamming, 

-  exhaust  information  from  every  report, 

-  minimize  operator  vorkload  for  fusion  process, 

-  smooth  transition  from  active  to  passive 
tracking. 

All  this  is  possible  because  va  have  the  capacity 
to  update  a  track  by  using  a  filter  vhich  is 
provided  vlth  a  meaauranant  sharing  loop,  which 
me  ana  that,  unlike  a  conventional  filter  (or  benk 
of  filters),  partial  aslauth,  range  or  elevation 
measurements  can  be  introduced  in  the  filter. 


So,  THOMSON-CSF  has  made  possible  automatic 
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updating  of  multisensor  tracks  vith  : 

-  "normal"  plots  only, 

-  "normal"  plots  and  stroba  plots, 

-  exclusively  strobe  plots. 


3.3.  Sensor  Management 

The  increase  of  threat  variety  and  perforaance 
require  system  adoption  to  theater  constraints 
and  situation  and  need  to  exploit  the  full 
spectrum  of  sensors  diversity  performance  and 
adaptativity  features.  This  cannot  be  done 
manually  so  there  is  a  need  for  an  automatic 
multisensor  management  function.  This  function 
operates  on  operational  directives  vhich  are 
expressed  in  such  a  vay  : 

-  improve  surveillance  in  such  and  such  areas, 

-  operate  in  discrete  mode  (still  maintaining 
sufficient  quality  of  the  air  picture), 

-  Increase  detection  capability  for  small  RCS 
targets  in  such  penetration  corridor, 

-  implement  emission  plan,  vhich  may  lead  to 
reduce  the  use  of  fev  sensors  in  defined 
sectors. 

However,  very  direct  orders  can  still  be  issued 
at  this  level,  such  as  : 

-  stop  radar  emission  or  lov  power  emission  (in 
front  of  ARM  attack  for  instance), 

-  set  a  high  priority  quality  in  the  updating  for 
specifically  designated  tracks. 

To  fulfill  its  role  this  function  needs  to 
evaluate  the  multisensor  coverage.  This  evaluaton 
function  operates  from  information  provided  by 
different  sources  :  from  the  geographical 
configuration  of  the  system  (ground,  sensors 
locations),  from  the  environmental  data  provided 
by  the  radars  or  by  the  operator  and  evaluates 
the  quality  of  the  multisensor  coverage  of  the 
system  (in  real  time  or  in  an  off-line  prediction 
mode) . 

3.4.  HST/MP-VU  Advantages 

Mainly  the  THOMSON-CSF' s  MP-VU  tracker  features 
the  following  : 

-  broad  use  of  the  sensor  coverage  redundancy 
through  the  full  processing  of  every  sensor 
data  as  soon  as  it  is  reported, 

-  very  high  level  of  performance  reached  :  short 
automatic  track  initiation,  quick  target 
manoeuver  detection  and  accurate  track  position 
during  air  vehicle  changes  in  speed,  heading 
and  altitude, 

-  benefit  from  the  increase  of  target  detection 
probability  provided  by  the  multisensor 
coverage, 

-  ability  to  process  a  broad  variety  of  sensor 
data  such  as  30  and  20  plots  with  or  vithout 
range  rate,  strobe  data,  vith  associated 

measurement  errors, 

-  robustness  against  jamming  thanks  to  partial 
measurement  processing  capability  (track  update 
on  strobe  data,  process  of  intersection  of 
strobes  from  non-colocated  sensors), 

-  automatic  sensor  monitoring,  assessment  of 


sensor  biases  and  adjustment  of  sensor  data 
concurrently  vith  the  air  picture  production. 

The  high  level  of  perforaance  reached  has  been 
validated  by  tracking  results  obtained  from  the 
data  on  real  sites  vhere  THOMSON-CSF  has 
integrated  the  MST/HP-VU  technique.  From  the 
operational  experience  on  one  hand  and  from 
studies  in  process  on  existing  airborne  systems 
of  future  ones  on  the  other  hand,  THOMSON-CSF 
prepares  new  solutions  based  on  a  distributed 
netvork  of  fixed  and  mobile  sensors. 


4.  POSSIBLE  EVOLUTIONS 

Air  vehicles  are  both  part  of  the  air  picture  and 
users  of  this  picture.  Vhen  secure  high  quality 
communication  means  vlll  be  commonly  integrated 
on  board,  then  air  vehicles  participate  to  the 
air  picture  production  sending  their  own 
detection  measures,  because  this  data  vill  be 
very  accurate  time  stamped  and  well  located  (MIDS 
data  for  ‘instance).  Furthermore,  these  air 
vehicules  vould  receive  at  filtered  air  picture 
back  from  the  ground  based  multisensor  tracking. 
So,  their  local  situation  vill  be  increased  and 
their  own  mission  vill  be  modified  by  the  ability 
to  start  transmitting  on  board  sensors  at  the 
last  phase. 


S.  CONCLUSION 

In  conclusion,  vhen  such  an  implementation  of  the 
surveillance  fonction  and  its  relevant  advantage 
is  compared  to  the  concerns  relative  to  mobility 
of  air  surveillance  systems,  the  following  matrix 
appears.  It  underlines  the  apropr lateness  of  this 
solution  for  the  air  situation  establishment  in  a 
multisensor  environment. 

Less  poverfull  sensors 
A 

I 

V 

-  Benefit  of  the  multisensor  coverage  integration 
of  various  sensors  and  airborne  sensor  systems 

Unaccurate  sensor  location 
A 

I 

V 

-  Automatic  sensor  registratlon/allgnaent 

-  Use  of  air  vehicle  position  reports  compared  to 
track/target  position 


Changes  in  sensor  netvork  (in  number  and  in  shape) 
A 

I 

V 

-  MP-VU  is  monosensor  for  each  set  of  data/track 
update 

-  Sensor  management 
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SUMMARY 

Paladin  is  a  real-time  tactical  decision 
generator  for  air  combat  engagements.  Paladin 
uses  specialized  knowledge-based  systems 
and  other  Artificial  Intelligence  (AI) 
programming  techniques  to  address  the 
modem  air  combat  environment  and  agile 
aircraft  in  a  clear  and  concise  manner.  Paladin 
is  designed  to  provide  insight  into  both  the 
tactical  benefits  and  the  costs  of  enhanced 
agility.  The  system  was  developed  using  the 
Lisp  prograimning  language  on  a  specialized 
AI  workstation.  Paladin  utilizes  a  set  of  air 
combat  rules,  an  active  throttle  controller,  and 
a  situation  assessment  module  that  have  been 
implemented  as  a  set  of  highly  specialized 
knowledge-based  systems.  The  situation 
assessment  module  was  developed  to 
determine  the  tactical  mode  of  operation 
(aggressive,  defensive,  neutral,  evasive,  or 
disengagement)  used  by  Paladin  at  each 
decision  point  in  the  air  combat  engagement. 
Paladin  uses  the  situation  assessment  module 
and  the  situationally  dependent  modes  of 
operation  to  more  accurately  represent  the 
complex  decision-making  process  of  human 
pilots.  This  allows  Paladin  to  adapt  its  tactics 
to  the  current  situation  and  improves  system 
performance.  This  paper  discusses  the  details 
of  Paladin’s  situation  assessment  and  modes 
of  operation.  The  results  of  simulation  testing 
showing  the  error  introduced  into  the  situation 
assessment  module  due  to  estimation  errors  in 
positional  and  geometric  data  for  the  opponent 
aircraft  are  presented.  Implementation  issues 
for  real-time  performance  are  discussed  and 
several  solutions  are  presented,  including 


Paladin’s  use  of  an  inference  engine  designed 
for  real-time  execution. 

J _ INTRODUCTION 

Modem  air  combat  simulations  require  an 
intelligent  system,  called  a  Tactical  Decision 
Generator  (TDG) ,  to  select  the  combat 
maneuvers  to  perform  throughout  an  air 
combat  engagement  The  simulation  system 
must  also  have  the  ability  to  model  agile 
aircraft  The  system  should  have  a  modular 
software  structure  so  that  new  weapons 
systems  or  aircraft  subsystems  (e.g.  sensors  or 
propulsion  systems),  modifications  to  aircraft 
control  systems,  or  changes  to  the  aircraft 
configuration  can  be  easily  incorporated.  In 
support  of  the  study  of  superagile  aircraft  at 
Langley  Research  Center  (LaRC),  a  Tactical 
Guidance  Research  and  Evaluation  System 
(TiGRES)  is  being  developed.  The  design  and 
development  of  TiGRES  as  well  as  its 
relationship  to  other  current  air  combat 
simulation  systems  is  described  in  detail  in 
references  1*2*3- 

The  TiGRES  system  is  designed  to  allow 
researchers  to  develop  and  evaluate  aircraft 
systems  in  a  tactical  environment  The  three 
main  components  of  TiGRES  are  a  TDG,  the 
Tactical  Maneuver  Simulator  (TMS),  and  the 
Differential  Maneuvering  Simulator  (DMS). 
Both  the  TMS  and  the  DMS  use  a  TDG  as  the 
intelligent  automated  opponent 

The  TMS1*3  provides  a  high-fidelity  batch 
air  combat  simulation  environment  for  the 
development  and  testing  of  various  guidance 
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and  control  strategies.  The  researcher  defines 
the  initial  conditions  of  the  air  combat 
engagement  and  the  TMS  then  controls  the 
trajectories  and  attitudes  of  the  aircraft  using 
simple  trajectory  commands,  or  through  a 
tactical  decision  generation  system.  The  main 
elements  of  the  TMS  are  a  high-fidelity, 
nonlinear  six  degree-of-freedom  (d.o.f.)  rigid- 
body  aircraft  dynamic  model,  including  the 
control  system,  a  TDG,  and  a  user  interface. 

The  DMS  consists  of  two  40’  diameter 
domes  and  one  20'  diameter  dome.  The 
facility  is  intended  for  the  real-time  simulation 
of  air  combat  engagements  between  piloted 
aircraft  By  using  a  TDG  to  control  one  of  the 
airplanes,  it  is  possible  to  test  a  TDG  against  a 
human  opponent  This  feature  allows  the 
guidance  logic  to  be  evaluated  against  one  or 
more  unpredictable  and  adaptive  human 
opponents. 


Paladin  is  a  knowledge-based  TDG 
designed  to  provide  insight  into  both  the 
tactical  benefits  and  tire  costs  of  superagility. 
Knowledge-based  systems  use  a  large  amount 
of  information  about  a  problem's  domain  to 
understand  and  solve  that  problem.  Paladin 
was  developed  in  the  Lisp  programming 
language  using  a  Symbolics  3650+ 
workstation. 

The  development  of  Paladin  has  been  a 
multi-stage  process  using  a  baseline  version  of 
the  Adaptive  Maneuvering  Logic  4  (AML) 
program  as  the  starting  point.  Paladin  uses  the 
trial  maneuver  generation  and  evaluation 
concept  outlined  in  the  AML  program  4  with 
several  extensions.  The  original  set  of  five  to 
nine  aircraft  trial  maneuvers  used  by  AML  has 
been  replaced  with  four  sets  of  positionally 
dependent  trial  maneuvers.  Past  research 
has  shown  that  the  use  of  the  positionally 
dependent  sets  of  trial  maneuvers  improves 
overall  system  performance,  allows  Paladin  to 
perform  target  acquisition  and  tracking  more 
effectively,  and  improves  Paladin’s  defensive 
and  evasive  maneuvering  performance. 

+  Symbolics  3650  is  a  registered  trademark  of 
Symbolics  Incorporated 


Paladin  uses  an  object-oriented  programming 
approach  5  to  represent  each  aircraft  in  the 
simulation.  Each  aircraft  object  includes 
information  on  the  current  state  of  the 
aircraft’s  offensive  systems  (e.  g.  guns, 
missile  systems,  fire  control  radars,  etc.), 
defensive  systems  (e.  g.  electronic  counter¬ 
measures,  chaff,  etc.),  and  propulsion  system. 
This  state  information  is  used  to  help  guide 
Paladin’s  reasoning  process. 

Paladin  utilizes  modular  software 
subroutines  and  specialized  computer 
hardware.  The  separation  of  the  aircraft 
simulation  and  decision  logic  components,  and 
the  use  of  highly  specialized  knowledge 
sources,  allows  each  module  or  knowledge 
source  to  be  designed  and  implemented  using 
the  hardware  and  programming  techniques 
specifically  suited  for  its  function.  The  use  of 
highly  specialized  and  independent  knowledge 
sources  also  provides  for  modular  protection5, 
confining  the  effect  of  an  error  occurring  in  a 
module  at  run-time  to  that  module,  or  to  a 
small  set  of  neighboring  modules  in  the 
program.  The  confining  effect  of  the  modular 
protection  was  used  to  aid  in  the  design  and 
debugging  process.  Each  knowledge  source 
was  developed  and  tested  independently  before 
it  was  incorporated  into  Paladin. 

The  independence  of  the  knowledge 
sources  also  increases  the  efficiency  of  Paladin 
by  allowing  knowledge  sources  to  be 
distributed  across  a  network  of  several 
heterogeneous  processors.  The  network 
currently  consists  of  a  Symbolics  3650 

workstation,  a  Symbolics  MacIvory+ 
workstation,  two  SUN+  SPARC  class 
workstations,  and  four  Vax  3200+  class 
workstations.  Communication  between  the 
distributed  knowledge  sources  is  achieved 
using  customized  DECNet-based 
Client/Server  software  developed  in-house  for 
TiGRES.  This  software  allows  for 

+  Maclvory  is  a  registered  trademark  of 
Symbolics  Incorporated, 
t  SUN  is  a  registered  trademark  of  Sun 
Microsystems  Incorporated. 

+  Vax  3200  &  DECNet  are  registered 
trademarks  of  Digital  Equipment  Corporation. 


synchronization,  communications,  and  data 
sharing  between  heterogeneous  computers 
running  the  DECNet  communications 
protocol.  TCP/IP  based  communications 
software  has  also  been  developed  in-house  for 
the  SUN  workstations.  Paladin  is 
implemented  as  a  serial  blackboard  system,  so 
no  serialization  or  concurrency  related 
software  is  required6.  Each  knowledge  source 
requests  all  of  the  data  required  to  perform  its 
computation  from  the  blackboard  at  the  start  of 
its  execution  cycle,  and  posts  its  results  to  the 
blackboard  at  the  end  of  its  execution  cycle. 

2.1  The  Paladin  Inference  Engine 

The  Paladin  knowledge  sources  use  a 
custom  inference  engine  (see  appendix  A)  that 
was  designed  to  support  real-time  execution  of 
knowledge-based  systems.  The  inference 
engine  uses  a  depth-first  evaluation  strategy  5 
to  search  the  active  rule-bases.  Rule-bases 
can  be  partitioned,  and  the  partitions  are  linked 
using  meta-rules  (rules  used  to  guide  the 
activation  of  rule-bases).  Rule-bases  are 
expressed  in  two  formats:  interpreted  lists  of 
condition  action  pairs  used  during  the  design 
stage,  and  compiled  lists  of  in-line  function 
definitions  used  in  the  final,  real-time  version 
of  the  system.  The  interpreted  lists  are  used  to 
develop  and  debug  the  initial  versions  of  the 
rule-base.  Most  existing  rule-based  systems 
stop  development  at  this  point  and  implement 
the  interpreted  rule-bases.  The  use  of  the 
interpreted  rules  severely  limits  the  execution 
performance  of  the  inference  engine,  and 
restricts  the  real-time  usage  of  this  type  of 
system.  To  overcome  this  problem  and  allow 
real-time  execution,  the  rule-base  is 
“compiled”  into  a  list  of  in-line  functions.  The 
rule-base  compiler  was  developed  in-house 
and  is  written  in  Lisp  for  execution  on  an  AI 
workstation.  The  compiled  rule-bases  execute 
approximately  90  to  100  times  faster  than  the 
interpreted  rules.  The  inference  engine 
executes  a  representative  test  rule-base 
consisting  of  40  rules  in  the  interpreted  format 
in  170  milliseconds.  The  inference  engine 
executes  the  same  rule-base  in  the  compiled 
format  in  1.9  milliseconds. 

There  is  a  trade-off  between  the  length  of 
the  rule-base’s  longest  execution  path  and  the 


knowledge  source’s  execution  time.  The 
shorter  the  execution  path  is,  the  faster  the 
execution  time.  The  rule-bases  used  by 
Paladin  have  been  partitioned  to  increase 
system  performance  by  grouping  related  rules 
into  small  partitions  and  using  meta-rules  to 
link  the  partitions.  This  partitioning  decreases 
the  number  of  rules  that  are  active,  and 
decreases  the  length  of  the  worst-case 
execution  path  through  the  rule-base.  The 
rule-base  partitioning  allows  the  designer  to 
calculate  the  longest  and  shortest  path  through 
the  rule-base  and  compute  both  a  maximum 
and  minimum  knowledge  source  execution 
time.  The  knowledge  source’s  maximum 
execution  time  can  be  used  to  insure  that  the 
system  will  meet  real-time  execution 
requirements.  If  the  maximum  execution  time 
exceeds  the  allocated  execution  time,  the 
designer  may  be  able  to  repartition  the  rule- 
base  until  real-time  execution  requirements  are 
achieved. 

Paladin  uses  two  rule-bases:  a  mode 
selection  rule-base  used  by  the  Situation 
Assessment  knowledge  source,  and  a  throttle 
control  rule-base  used  by  the  Active  Throttle 
Controller.  The  mode  selection  and  throttle 
control  rule-bases  are  included  in  appendices 
B  and  C.  The  mode  selection  rule-base 
consists  of  four  partitions  and  contains 
nineteen  rules.  The  shortest  execution  path  in 
this  rule-base  results  in  a  single  rule  being 
fired;  the  longest  path  results  in  twelve  rules 
being  fired.  The  throttle  control  rule-base 
consists  of  ten  partitions  and  contains  forty 
rules.  The  shortest  execution  path  in  this  rule- 
base  results  in  a  two  rules  being  fired;  the 
longest  path  results  in  thirteen  rules  being 
fired. 

2.2  Situation  Assessment  Module 

Six  modes  of  operation,  shown  in  table  1, 
have  been  incorporated  in  Paladin.  As  shown 
in  Figure  1,  the  Situation  Assessment 
knowledge  source  is  executed  before  the 
maneuver  scoring  module.  The  Situation 
Assessment  knowledge  source  uses  the  mode 
selection  rule-base  (appendix  B)  to  determine 
the  system’s  current  mode  of  operation.  This 
knowledge  source  is  used  to  model  a  pilot’s 
situational  awareness  and  changing  problem¬ 
solving  strategies.  Just  as  a  pilot  will 


Figure  1 .  Schematic  Of  Paladin 


recognize  the  difference  between  an  aggressive 
situation  and  a  evasive  situation  and  react 
accordingly,  the  Situation  Assessment 
knowledge  source  provides  information 
allowing  Paladin  to  adapt  its  problem-solving 
strategy  based  on  the  current  situation.  The 
determination  of  the  current  mode  of  operation 
is  based  on  the  aircraft's  current  mission,  the 
current  state  of  the  aircraft's  systems,  the 
relative  geometry  between  the  aircraft  and  its 
opponent,  and  the  opponent's  instantaneous- 
intent  (defined  later).  Each  of  the  six  modes  of 
operations  has  a  unique  vector  of  scoring 
weights  and  a  unique  decision  interval  (shown 
in  table  1).  The  scoring  weights2  for  each 
mode  of  operation  have  been  adjusted  during 
the  design  and  testing  process  to  maximize 
Paladin's  performance  in  that  mode  of 
operation.  The  testing  procedures  used  to 
evaluate  Paladin’s  performance  are  described 
in  detail  in  section  3. 

Both  TMS  and  DMS  test  results1*2  have 
shown  that  a  short  decision  interval  (0.23  sec.) 
improves  Paladin’s  fine-tracking  performance 
in  aggressive  situations,  and  Paladin’s 
maneuvering  capabilities  in  evasive  situations. 


In  neutral  or  defensive  situations  the  same 
short  decision  interval  results  in  a  "thrashing" 
motion,  degrading  system  performance.  The 
thrashing  is  due  to  the  system 
overcompensating  for  small  changes  in  the 
opponent’s  motion.  These  thrashing 
maneuvers  bleed  off  energy  and  reduce 
Paladin’s  effectiveness;  thus  a  longer  decision 
interval  is  used  in  defensive  (0.5  sec.)  and 
evasive  situations  (1.0  sec.). 


The  situation  assessment  knowledge 
source  also  determines  the  opponents 
instantaneous-intent  The  opponent's 
instantaneous-intent  is  defined  to  be  an 
estimation  of  the  opponent’s  mode  of 
operation  at  the  current  point  in  time  based  on 
Paladin’s  available  sensor,  positional,  and 


geometric  data.  Currently,  there  is  no  attempt 
to  use  a  history  of  instantaneous-infrnt  to 
derive  a  long-term  opponent  intent 


2.2.1  Situation  Assessment  Data 

To  perform  situation  assessment, 
information  on  aircraft  relative  geometry  and 
Paladin’s  system  status  is  required.  This 
information  is  available  in  the  form  of 
participant-specific  data  maintained  by  Paladin. 
All  data  relating  to  the  Paladin  aircraft  as  well 
as  Paladin  sensor  data  (e.g.  the  opponent’s 
relative  position)  are  assumed  to  be  known 
exactly.  Other  data  required  about  the 
opponent  must  be  estimated. 


between  the  LOS  vector  and  the  ownship  body 
x-axis  (see  figure  2);  the  deviation  angle  is 
defined  as  the  angle  between  the  LOS  vector 
and  the  ownship  velocity  vector,  and  the  LOS 
angle  off  is  defined  as  the  angle  between  the 
LOS  vector  and  the  opponent's  body  x-axis. 

The  deviation  angle  is  calculated  as  the 
inverse  cosine  of  the  magnitude  of  the 
projection  of  the  range  onto  the  velocity  vector 
divided  by  the  range.  In  equation  form. 


deviation  angle  = 

[xAx  +  yAy  +  zAz 
(Range)  |Velocityl 


arccosl 


] 


0) 


The  line-of-sight  angle  (LOS)  is  the  inverse 
cosine  of  the  magnitude  of  the  projection  of  the 
range  onto  the  x-body  axis  divided  by  the 
range,  or. 


LOS  angle  = 

|D(l,l)Ax  +  D(l,2)Ay  + 


arccos 


Range 


D(l,3)Azj 

(2) 


where  Ax,  Ay,  and  Az  represent  the  difference 
between  the  two  aircraft  positions.  D(i  j)  is 
the  i,  j  element  of  the  Paladin  body  axis 
direction  cosine  matrix.  Then  the  LOS 
elevation  is  taken  to  be  the  inverse  sine  of 
minus  the  opponent’s  z-coondinate  in  the 
Paladin  body  axis  system  divided  by  the 
range,  or, 

LOS  elevation  = 


arcsin 


opponent  in  Paladin  body  axis  system 


Range 


(3) 


The  quantities  used  by  the  situation 
assessment  module  which  are  based  on  exactly 
known  data  are  either  specific  to  the  Paladin 
aircraft  or  are  relative  values  from  the  Paladin 
aircraft’s  point  of  view.  Paladin’s  current 
throttle  position  and  altitude  are  parameters 
taken  directly  from  the  current  state.  Range  is 
the  magnitude  of  a  vector  connecting  the 
centers  of  gravity  of  the  aircraft  The  Line-Of- 
Sight  (LOS)  angle  is  defined  as  the  angle 


The  LOS  azimuth  is  the  inverse  tangent  of  the 
opponent’s  y-coordinate  divided  by  the 
opponent’s  x -coordinate,  both  in  the  Paladin 
body  axis  system. 


velocity  onto  the  range  axis  (all  in  the  inertial 
axis  system). 


X-6 


LOS  azimuth  = 


arc  tan 


^opponent  in  Paladin  body  axis  system 
LXopponent  in  Paladin  body  axis  systemj 


(4) 


Finally,  off  comer  is  the  proportion  by  which 
Mach  number  differs  from  the  instantaneous 
cornering  Mach  number  (speed  to  achieve 
largest  possible  turn  rate)  calculated  for  the 
current  altitude, 


off  comer  = 

Cornering  Mach  -  Current  Mach 
Cornering  Mach 


(5) 


The  velocity,  acceleration  and  orientation 
of  the  opponent  must  be  estimated,  since  this 
data  would  not  be  available  from  sensors. 
These  estimates  are  made  using  a  three  point 
time  history  of  the  known  position  data  and 
several  assumptions  about  the  opponent 
aircraft  (weight,  wing  surface  area,  and  flight 
characteristics).  The  current  position  of  the 
opponent  and  the  opponent’s  position  at  the 
preceding  two  decision  cycles  are  used  to  find 
a  quadratic  curve  fit  for  the  position  as  a 
function  of  time.  The  first  and  second 
derivatives  of  this  function  at  the  current  time 
yield  an  estimation  of  the  opponent’s 
instantaneous  velocity  and  acceleration.  By 
assuming  aerodynamic  characteristics  of  the 
opposing  aircraft,  and  using  the  velocity  and 
acceleration  estimates,  an  estimated  body-axis 
orientation  for  the  opponent  can  be  found. 

The  quantities  used  by  the  situation 
assessment  module  which  are  based  on 
estimated  data  are  largely  relative  values  from 
the  opponent  aircraft’s  point  of  view.  Each  of 
these  quantities  has  some  error  introduced  by 
the  estimation  process.  The  range  rate  is  the 
magnitude  of  the  projection  of  the  relative 


AxAx  +  AyAy  +  AzAz 
""Seraie - - 


(6) 


The  opponent’s  deviation  angle  and  line-of- 
sight  angle  are  calculated  similarly  to  the 
Paladin  aircraft  parameters  (equations  1  and 
2),  using  the  opponent’s  velocity  and  x-body 
axis.  Paladin’s  LOS  angle  off  is  defined  as 
180°  -  opponent’s  LOS  angle.  The  errors 
between  the  actual  parameter  values  and  the 
estimated  values  were  calculated  for  a 
representative  set  of  32  within-visual-range 
engagements3,  resulting  in  the  sample  means 

(X)  and  standard  deviations  (s)  listed  in  table  2 

(for  a  sample  size  of  7369).  Figures  3  through 
5  show  each  of  these  error  magnitudes 
(absolute  value  of  the  actual  value  minus  the 
estimated  value)  during  the  course  of  a  typical 
engagement  Error  expectations  given  in  table 
2  and  magnitudes  given  in  the  figures  are 
based  on  engagements  between  Paladin  and  an 
opponent  with  known  aerodynamic 
characteristics.  If  the  aerodynamics  of  the 
opponent  aircraft  are  not  well  known,  the  error 
in  the  LOS  angle  should  increase,  since  this 
error  is  strongly  dependent  on  the  aircraft 
flight  characteristics. 

From  the  same  set  of  32  engagements, 
results  were  collected  on  the  sensitivity  of  the 
situation  assessment  module  to  these 
estimation  errors.  The  correct  mode  of 
operation  (the  mode  selected  given  exact  data 
for  all  inputs)  was  chosen  98.0%  of  the  time. 
Hence,  this  implementation  of  the  situation 
assessment  knowledge  source  is  believed  to  be 
insensitive  to  the  errors  introduced  by  data 
estimation.  Past  research2  has  shown  Paladin 
to  be  insensitive  to  errors  due  to  typical  levels 
of  sensor  noise  in  the  opponent’s  positional 
data. 


Table  2.  Error  Statistics 


|  Range  Rate  Error  (ft/sec) 

Deviation  Error  (deg) 

LOS  Error  (deg)  1 

X 

s 

X 

s 

X 

s 

1.52 

mm 

2.3  Active  Throttle  Conti  oiler 

A  rule-based  Active  Throttle  Controller 
was  developed  to  adjust  the  throttle  setting 
based  on  the  current  mode  of  operation.  The 
throttle  controller  is  called  at  the  start  of  each 
decision  interval  and  can  set  the  throttle  to  any 
posidon  between  idle  and  full  afterburner  [0.0 
=  flight  idle,  ..1.0  =  military  power,  ..2.0  = 
full  afterburner).  The  throttle  controller  uses 
the  throttle  control  rule-base  (appendix  C),  the 
current  mode  of  operation,  and  the  relative 
geometry  information  to  select  either  a  target 
acquisition  mode,  a  fine  tracking  mode,  or  a 
target  or  missile  avoidance  mode.  Each  mode 
has  a  set  of  specific  throttle  control  rules  that 
are  used  to  maximize  system  performance  in 
that  mode. 

The  active  throttle  controller  uses  the  same 
data  described  for  the  situation  assessment 
module,  and  so,  incurs  the  same  estimation 
errors.  Using  the  results  of  the  32 
engagements  discussed  in  the  previous 
section,  the  resulting  errors  in  the  selected 
throttle  position  have  been  evaluated.  The 
throttle  setting  chosen  by  the  active  throttle 
controller  was  within  +1-5%  of  the  correct 
setting  (the  position  selected  given  exact  data) 
in  95.8%  of  the  7369  cases  tested.  Table  3 
shows  the  distribution  of  these  errors  around 
the  correct  throttle  command.  For  this  table,  E 
is  the  error  band  (in  %)  of  the  throttle  position, 
and  P  is  the  percentage  of  the  test  cases  which 
fall  within  +/-  E  of  the  correct  position. 


Table  3.  Active  Throttle  Controller  Error 


- E - 

P 

5 

""95 

10 

95.83 

15 

95.90 

20 

97.15 

50 

99.38 

2.4  Maneuver  Scoring  Module 


The  Paladin  Maneuver  Scoring  Module 
knowledge  source  is  a  FORTRAN  subroutine. 
The  scoring  module  uses  a  set  of  fuzzy  logic 
questions3  with  responses  ranging  from  [-1.0 
=  Negative,  ..0.0  =  Neutral,  ..1.0  =  Positive] 


and  the  mode-specific  scoring  weight  vector 
selected  by  the  situation  assessment  module  to 
score  each  of  the  trial  maneuvers.  For  each 
trial  maneuver  evaluated  the  predicted 
positions  for  both  the  opponent  and  the 
Paladin  aircraft  are  computed.  The  position  of 
the  opponent  is  extrapolated  using  a  quadratic 
curve  fit  based  on  the  time  history  of  the 
opponent  aircraft's  trajectory  as  previously 
described.  The  future  position  of  the  Paladin 
aircraft  is  determined  by  predicting  tjie  result 
of  executing  the  control  commands  for  each 
candidate  trial  maneuver. 

Once  the  relative  geometry  between  the 
future  positions  of  the  two  aircraft  is 
calculated,  the  score  for  the  maneuver  is 
determined  by  computing  the  responses  to  the 
seventeen  fuzzy  logic  questions,  applying  the 
selected  scoring  weight  vector,  and  then 
summing  the  results  to  generate  a  single 
numeric  score.  After  all  of  the  trial  maneuvers 
have  been  evaluated,  the  highest  scoring 
maneuver  is  selected  and  the  associated  control 
commands  are  executed. 

2 _ Paladin  Testing  Procedures 

Paladin  is  currently  being  tested  in  the 
TMS  using  six  d.o.f.  aircraft  dynamics,  and  in 
the  DMS  using  five  d.o.f.  aircraft 
dynamics2*3.  TMS  testing  is  done  in  a  non- 
real-time,  batch  mode  environment  against  a 
baseline  TDG.  Each  group  of  test  conditions 
consists  of  32  sets  of  initial  aircraft  conditions. 
The  initial  altitudes,  airspeeds,  and  the 
separations  between  the  two  aircraft  are 
adjusted  to  provide  representative  coverage  of 
the  within-visual-range  air  combat  arena.  The 
largest  initial  aircraft  separation  currently  being 
tested  (5  nm)  places  the  aircraft  at  the  transition 
point  between  beyond- visual-range  and 
within-visual-range  air  combat. 

A  set  of  engagement  scoring  metrics 
(presented  in  reference  3,  and  outlined  in 
Appendix  D)  are  reviewed  after  each  set  of  test 
runs  and  the  data  are  used  to  tune  the  mode 
specific  scoring  weights  and  test  the 
completeness  of  the  knowledge  bases. 
Although  the  metrics  are  helpful,  no  single 
metric  has  been  developed  that  can  completely 
measure  the  performance  of  an  aircraft  in  the 


engagement  In  past  test  engagements  an 
aircraft  could  score  significant  amounts  of 
weapons  lock  time  after  it  had  been  "killed.” 
This  phenomenon  adversely  affected  several  of 
the  scoring  metrics.  To  correct  this  problem 
all  engagements  are  now  ended  when  the 
probability  of  survival  for  either  aircraft  is  less 
than  0.30. 

After  initial  adjustment  of  the  scoring 
weights,  the  set  of  initial  conditions  is 
expanded  to  320  initial  conditions  by 
modifying  the  initial  separation  between  the 
airplanes,  the  initial  altitudes,  and  the  initial 
Mach  numbers.  This  stepwise  refinement 
process  provides  the  large  set  of  results 
required  to  achieve  global  system 
improvements  across  the  total  wi thin-visual- 
range  air  combat  environment. 

A  baseline  version  of  Paladin  is  currently 
being  tested  in  the  DMS  using  a  5  d.o.f. 
aircraft  model.  The  aircraft  model  lacks  both 
the  extra  degree  of  freedom  (lateral  motion  in 
body  axes)  as  well  as  an  accurate 
representation  of  the  aircraft’s  rotational 
dynamics  throughout  the  complete  flight 
envelope.  The  baseline  Paladin  system,  the 
Computerized  Logic  for  Air  Warfare 
Simulation  (CLAWS)  contains  the  situation 
assessment  module,  the  active  throttle 
controller,  and  a  reduced  set  of  situationally 
dependent  trial  maneuvers.  This  reduced  set 
of  trial  maneuvers  and  the  simplified  aircraft 
model  are  used  to  insure  real-time  performance 
in  the  DMS. 

The  development  of  CLAWS  has  made  it 
possible  to  evaluate  the  tactical  decision 
generation  software  against  human  pilots  in  the 
DMS  in  a  realistic  air  combat  environment. 

This  capability  has  allowed  experienced  pilots 
to  interact  with  the  system  and  comment  on  its 
performance  and  suggest  improvements.  The 
pilots'  comments  and  suggestions  are  then  the 
basis  for  changing  the  TMS  experimental 
version  of  Paladin.  These  changes  are  tested 
and  refined  before  being  included  in  the 
baseline  system. 

4 _ Concluding  Remarks 

Paladin,  a  computerized  air  combat  tactical 
decision  generator,  has  been  developed  to 


study  within-visual-range  air  combat 
engagements.  The  system  incorporates 
modem  airplane  simulation  techniques, 
sensors,  and  weapons  systems.  The  system 
was  developed  using  several  concepts  first 
outlined  in  the  Adaptive  Maneuver  Logic 
program.  Paladin  uses  knowledge-based 
systems  and  Artificial  Intelligence  (AI) 
programming  techniques  to  address  air-to-air 
combat  and  agile  aircraft  in  a  clear  and  concise 
manner.  The  ability  to  integrate  Paladin  into 
the  Differential  Maneuvering  Simulator  offers 
a  unique  opportunity  to  evaluate  the 
performance  of  the  Al-based  Paladin  software 
in  a  real-time  tactical  environment  against 
human  pilots. 

Paladin  models  aspects  of  the  decision¬ 
making  processes  used  by  human  pilots 
through  the  use  of  the  Situation  Assessment 
knowledge-based  system.  The  use  of  distinct 
modes  of  operation  allows  Paladin  to  perform 
complex  air-to-air  combat  tasks  and  generate  . 
sound  tactical  decisions  in  real-time.  Paladin 
presents  an  excellent  opportunity  to  evaluate 
the  use  of  AI  programming  techniques  and 
knowledge-based  systems  in  a  real-time 
environment. 
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Appendix  A.  The  Paladin  Inference  Engine 

The  inference  engine  used  by  Paladin  is  designed  for  real-time  execution  of  complex  rules. 
The  inference  subroutine  accepts  a  rule-list  as  input  A  rule-list  consists  of  a  set  of  compiled  in¬ 
line  functions  developed  from  the  rule-base.  Each  rule  consists  of  a  condition  ->  action  pair.  The 
condition  clause  of  a  rule  can  be  any  function  that  returns  a  boolean  value  of  TRUE  ex  FALSE. 
The  action  clause  of  a  rule  can  be  any  computable  function,  including  calling  the  inference  engine 
with  another  rule-list.  The  Inference  subroutine  evaluates  the  condition  clause  of  the  first  rule  in 
the  rule-list  If  the  condition  evaluates  to  TRUE  the  action  clause  is  executed.  If  the  condition  is 
FALSE  inference  is  called  recursively  with  the  remaining  elements  in  the  rule-lisL 

(subroutine  inference  (rule-list) 

(If  rule-list  empty  ->  quit) 

(If  condition  clause  of  first  rule  is  TRUE  ->  execute  action  clause  and  quit) 

(Otherwise  ->  call  inference  on  the  rule-list  with  the  first  rule  removed)  ) 


Appendix  B.  Paladin  Mode  Select  Rules 

The  mode  select  rule-base  contains  five  partitions.  The  main  partition  contains  ten  rules.  The 
offensive-status-true  partition  contains  three  rules.  The  defensive-status-true  partition  contains 
two  rules.  The  offensive-status-false  partition  contains  three  rules,  and  the  defensive-status-false 
partition  contains  one  rule.  The  rules  are  used  to  determine  the  current  mode  of  operation  for 
Paladin  and  the  time  interval  at  which  tactical  decisions  are  made. 

The  rules  listed  in  the  mode  select  rule-base  presented  here  are  representative  of  the  rules  that 
are  currently  used  to  determine  Paladin’s  mode  of  operation.  This  set  is  not  intended  to  be  all 
inclusive  or  definitive. 

The  selection  process  is  started  by  sending  the  rule-list  to  the  inference  engine  shown  in 
Appendix  A. 

(Call  inference  mode-select-rules) 

(rule-list  mode-select-rules  (mode-rule- 1  mode-rule-2  mode-rule-3  mode-rule-4  mode-rule-5 

mode-rule-6  mode-rule-7  mode-rule-8  mode-rule-9  mode-rule- 10) ) 

(rule  mode-rule- 1 

(If  altitude  <=  50.0  ft  ->  set  mode  to  evasive  and  decision  cycle  to  0.25) ) 

(rule  mode-rule-2 

(If  relative  position  is  evasive  ->  set  mode  to  evasive  and  decision  cycle  to  0.25) ) 
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(rule  mode-rule-3 

(If  distance  home  >=  461.0  miles  ->  set  mode  to  disengage  and  decision  cycle  to  0.5) ) 
(rule  mode-rule-4 

(If  engine  status  is  not  perfect  ->  set  mode  to  disengage  and  decision  cycle  to  0.5) ) 

(rule  mode-rule-5  ■ 

(If  mission  is  evasive  ->  set  mode  to  evasive  and  decision  cycle  to  0.25) ) 

(rule  mode-rule-6 

(If  (mission  is  defensive  and  position  is  aggressive  or  neutral) 
or  (mission  is  neutral  and  position  is  aggressive)  -> 
set  mode  to  aggressive  and  decision  cycle  to  0.25) ) 

(rule  mode-rule-7 

(If  offensive  and  defensive  systems  are  up  -> 

Call  inference  offensive-system-true-list  and  Call  inference  defensive-system-true-list) ) 

(rule  mode-rule-8 
(If  offensive  systems  are  up  -> 

Call  inference  offensive-system-true-list  and  Call  inference  defensive-system-false-list) ) 

(rule  mode-rule-9 
(If  defensive  systems  are  up  -> 

Call  inference  defensive-system-true-list  and  Call  inference  offensive-system-false-list) ) 
(rule  mode-rule- 10 

(If  offensive  and  defensive  systems  are  down  -> 
set  mode  to  disengage  and  decision  cycle  to  1.0) ) 

************************************************************************ 
Offensive  Status  True  Rules. 

************************************************************************ 

(rule-list  offensive-status-true-list  (offense-true-rule-1  offense-true-rule-2  offense-true-rule-3)) 
(rule  offense-true-rule-1 

(If  mission  is  aggressive  and  position  is  aggressive  -> 
set  mode  to  aggressive  and  decision  cycle  to  0.25) ) 

(rule  offense-true-rule-2 

(If  mission  is  aggressive  and  position  is  neutral  •> 
set  mode  to  aggressive  and  decision  cycle  to  0.25) ) 

(rule  offense-true-rule-3 

(If  position  is  neutral  ->  set  mode  to  neutral  and  decision  cycle  to  1.0) ) 

************************************************************************ 
Defensive  Status  True  Rules. 

************************************************************************ 
(rule  list  defensive-status-true-list  (defense-true-rule-1  defense-true-rule-2)) 

(rule  defense-true-rule- 1 

(If  mission  is  aggressive  and  position  is  defensive  -> 
set  mode  to  aggressive  and  decision  cycle  to  0.25) ) 

(rule  defense-true-rule-2 

(If  position  is  defensive  ->  set  mode  to  defensive  and  decision  cycle  to  0.5) ) 


************************************************************************ 
Offensive  Status  False  Rules. 

************************************************************************ 

(rule-list  offensive-status-false- list  (offense-false-rule-1  offense-false-rule-2  offense-false-rule-3)) 
(rule  offense-false-rule-1 

(If  mission  is  aggressive  and  position  is  aggressive  -> 

(If  weapons  arc  functional  ->  set  mode  to  aggressive  and  decision  cycle  to  0.25) 
(Otherwise  ->  set  mode  to  neutral  and  decision  cycle  to  1.0) ) 

(rule  offense-false-rule-2 

(If  mission  is  aggressive  and  position  is  neutral  -> 

(If  weapons  are  functional  ->  set  mode  to  aggressive  and  decision  cycle  to  0.25) 
(Otherwise  ->  set  mode  to  disengage  and  decision  cycle  to  0.5) ) 

(rule  offense-false-rule-3 

(If  mission  is  neutral  and  position  is  neutral  -> 

(If  weapons  are  functional  ->  set  mode  to  neutral  and  decision  cycle  to  1 .0) 

(Otherwise  ->  set  mode  to  disengage  and  decision  cycle  to  0.5) ) 

************************************************************************ 
Defensive  Status  False  Rules. 

************************************************************************ 

(rule- list  defensive-status-false-list  (defense-false-rule- 1 )) 

(rule  defense-false-rule- 1 

(If  position  is  defensive  ->  set  mode  to  evasive  and  decision  cycle  to  0.25) ) 


Appendix  C.  Paladin  Throttle  Control  Rules 

The  throttle  control  rules  are  used  to  determine  the  current  throttle  position  for  Paladin.  The 
throttle  control  rule-base  contains  nine  partitions.  The  main  partition  contains  three  rules.  The 
big-range-list  partition  contains  two  rules.  The  med-range-list  partition  contains  seven  rules. 
The  small-range-list  partition  contains  five  rules.  The  comer-list  partition  contains  three  rules. 
The  set-range-list  partition  contains  four  rules.  The  push-list  partition  contains  three  rules.  The 
hold-list  partition  contains  three  rules,  and  the  reel-list  partition  contains  five  rules. 

The  rules  listed  in  the  throttle  control  rule-bases  presented  here  are  representative  of  the  rules 
that  are  currently  used  to  determine  Paladin’s  throttle  position.  This  set  is  not  intended  to  be  all 
inclusive  or  definitive. 

The  selection  process  is  started  by  sending  the  rule-list  to  the  inference  engine  shown  in 
Appendix  A.  If  the  rule  currently  being  evaluated  has  “TRUE”  as  the  condition  clause,  the  action 
is  always  taken. 

(Call  inference  throttle-rules) 

(rule-list  throttle-rules  (throttle-rule- 1  throttle-rule-2  throttle-rule-3)) 

(rule  throttle-rule- 1 

(If  range  >  20000.0  ft  ->  Call  inference  big-range-list) ) 

(rule  throttle-rule-2 

(If  1000.0  ft  <  range  <=  20000.0  ft  ->  Call  inference  med-range-list) ) 

(rule  throttle-rule-3 

(If  range  <=  1000.0  ft  ->  Call  inference  small-range-list) ) 
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************************************************************************ 

Big-Range-List 

************************************************************************ 

(rule-list  big-range-list  (big-range-rule- 1  big-range-rule-2)) 

(rule  big-tange-nile-1 
(If  I  see  him  ->  set  throttle  =*  2.0) ) 

(rule  big-range-rule-2 
(TRUE  ->  Call  inference  comer-list) ) 

************************************************************************ 

Med-Range-List 

************************************************************************ 

(rule-list  medium-range-list  (medium-range-rule- 1  medium-range-rule-2  medium-range-rule-3 

medium-range-rule-4  medium-range-rule-5  medium-range-rule-6 
medium-range-rule-7) ) 


(rule  medium-range-rule- 1 

(If  I  see  him  and  he  can’t  see  me  and  range  <=  7500.0  ft  ->  Call  inference  comer-list) ) 

(rule  medium-range-rule-2 

(If  I  see  him  and  he  can’t  see  me  and  range  >  7500.0  ft  ->  set  throttle  =  2.0)  ) 

(rule  medium-range-rule-3 

(If  I  see  him  and  he  can’t  see  me  and  I’m  infront  of  him  ->  Call  inference  comer-list) ) 

(rale  medium-range-rule-4 

(If  I  see  him  and  he  can’t  see  me  and  I’m  not  infront  of  him  ->  Call  inference  setrange-list) ) 
(rale  medium-range-rule-5 

(If  I  can’t  see  him  and  he  can  see  me  and  he  is  inftont  of  me  ->  Call  inference  comer-list) ) 
(rale  medium-range-rule-6 

(If  I  can’t  see  him  and  he  can  see  me  and  he  is  not  infront  of  me  ->  set  throttle  =  2.0) ) 

(rale  medium-range-rule-7 

(If  I  can’t  see  him  and  he  can’t  see  me  ->  Call  inference  comer-list) ) 

************************************************************************ 

Small-Range-List 

************************************************************************ 

(rale-list  small-range-list  (small-range-rale- 1  small-range-rale-2  small-range-rale-3 

small-range-rale-4  small-range-rale-5) ) 


(rale  small-range-rale-1 

(If  I’m  not  inftont  of  him  and  he  is  not  infront  of  me  ->  Call  inference  comer-list) ) 
(rale  small-range-rale-2 

(If  I’m  not  inftont  of  him  and  he  is  inftont  of  me  ->  Call  inference  setrange-list) ) 
(rale  small-range-rule-3 

(If  I’m  inftont  of  him  and  he  is  not  inftont  of  me  and 

(range  <  500.0  ft  or  range  rate  <  0.0  ft/sec)  ->  set  throttle  =  0.0) ) 

(rate  small-range-rale-4 

(If  I’m  inftont  of  him  and  he  is  not  infront  of  me  and 

range  >-  500.0  ft  and  range  rate  >=  0.0  ft/sec  ->  set  throttle  =  2.0) ) 
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(rule  small-range-rule-5 

(If  I’m  infront  of  him  and  he  is  infront  of  me  ->  Call  inference  comer-list) ) 

************************************************************************ 

Comer-List 

************************************************************************ 
(rule-list  comer-list  (comer-rule- 1  comer-rule-2  comer-rule- 3)) 

(rule  comer-rule- 1 

(If  off  comer  <  -0.1  ->  set  throttle  =  max  (0.5,  previous  throttle  *  (1.0  -  off  comer))) ) 
(role  comer-rule-2 

(If  off  comer  >  0.1  ->  set  throttle  =  previous  throttle  *  (1.0  -  off  comer)) ) 

(rale  comer-rule-3 

(TRUE  ->  set  throttle  =  previous  throttle) 

************************************************************************ 

Setrange-List 

************************************************************************ 
(role-list  setrange-list  (setrange-rule-1  setrange- role-2  setrange-role-3  setrange-role-4)) 

(role  setrange -rule- 1 

(If  range  >  15000.0  ft  ->  set  throttle  =  2.0) ) 

(rale  setrange-rule-2 

(If  12000.0  ft  <  range  <=  15000.0  ft  ->  Call  inference  reel-list) ) 

(rule  setrange-rule-3 

(If  7500.0  ft  <  range  <=  12000.0  ft  ->  Call  inference  hold- list) ) 

(rale  setrange-rule-4 

(If  range  <=  7500.0  ft  ->  Call  inference  push-list) ) 

************************************************************************ 

Push-List 

************************************************************************ 


(role-list  push-list  (push-rule- 1  push-rule-2  push-role-3)) 

(rule  push-rule- 1 

(If  separating  very  fast  ->  set  throttle  =  previous  throttle  *  0.95) ) 

(rule  push-rule-2 

(If  separating  fast  ->  set  throttle  =  previous  throttle  *  0.9) ) 

(rule  push-rule-3 

(TRUE->  set  throttle  =  previous  throttle  *  0.6) ) 

************************************************************************ 

Hold-List 

************************************************************************ 


(rule-list  hold-list  (hold-role- 1  hold-role-2  hold-role-3)) 

(rule  hold-rule- 1 

(If  separating  fast  or  very  fast  ->  set  throtde  =  max  (0.5,  previous  throttle  *  1.05)) ) 


(rule  hold-rule-2 

(If  closing  fast  or  very  fast  ->  set  throttle  =  previous  throttle  *  0.95) ) 

(rule  hold-rule-3 

(TRUE  ->  set  throttle  =  previous  throttle) ) 

************************************************************************ 

Reel-List 

************************************************************************ 

(rule-list  reel-list  (reel-rule- 1  reel-rule-2  reel-rule-3  reel-rule-4  reel-rule-5)) 

(rule  reel-rule- 1 

(If  closing  very  fast  ->  set  throttle  =  previous  throttle  *  0.9) ) 

(rule  reel-rule-2 

(If  closing  fast  ->  set  throttle  =  previous  throttle) ) 

(rule  reel-rule-3 

(If  closing  slowly  ->  set  throttle  =  max  (0.5,  previous  throttle  *  1.1)) ) 

(rule  reel-rule-4 

(If  separating  fast  or  very  fast  separating-fast  ->  set  throttle  =  2.0) ) 

(rule  reel-rule-5 

(TRUE  ->  set  throttle  =  max  (0.5,  previous  throttle  *  1.2)) ) 


Appendix  D.  Engagement  Scoring  Metrics 

Four  sewing  metrics  are  currently  used  to  evaluate  each  air  combat  engagement.  All  metrics 
are  computed  at  the  aircraft  simulation  upda*  rate  of  32  times  per  second.  The  first  metric  consists 
of  the  total  time  that  each  airplane  has  its  weapons  locked  on  its  opponent,  the  probability  that  any 
weapons  fired  will  hit  the  opponent,  the  distance  between  the  opponents,  the  angle-off,  and  the 
deviation  angle.  The  results  are  printed  in  a  table  format  at  the  completion  of  each  run. 

The  second  scoring  metric  computes  a  Probability  of  survival  (Ps)  using  the  data  computed  by 
the  first  metric.  The  probability  to  hit  for  an  all-aspect  missile  and  for  the  cannon  are  computed 
using  the  range  and  LOS  angle  to  the  opponent.  The  probability  to  hit  for  a  tail-aspect  missile  is 
computed  using  the  range,  the  LOS  angle  to  the  opponent,  and  the  LOS  angle  off.  Aircraft 
missiles  are  treated  as  limited  resources  and  a  probability  to  hit  of  0.65  is  required  to  launch  the 
first  missile.  The  probability  to  hit  threshold  increases  by  0.05  for  each  missile  launched.  An 
estimated  flyout  time  (the  time  it  will  take  a  missile  to  reach  it’s  target)  for  each  missile  is  computed 
based  on  the  launch  parameters,  and  another  missile  cannot  be  fired  until  the  flyout  time  has 
passed.  The  Ps  for  an  aircraft  then  is 

Ps  =  1.0  - 1  [probability  to  hit  *  Ps(01 

(D.l) 

summing  over  each  weapon  fired  by  the  opposing  aircraft.  Ps(f)  represents  the  Ps  of  the  aircraft 
firing  the  weapon  at  the  time  the  weapon  was  fired. 

The  third  scoring  metric  attempts  to  determine  a  Lethal  Time  (LT)  advantage  for  each 


engagement  Lethal  time  advantage  attempts  to  weigh  the  lethality  of  each  distinct  type  of  weapons 
lock  time. 


Paladin  Gun  •  Opponent  Gun 


(2  *  (Paladin  Tail-Aspect  -  Opponent  Tail-Aspect))  + 

(Paladin  All-Aspect  -  Opponent  All-Aspect ) 

(D.2) 

A  positive  lethal  time  value  shows  Paladin  with  a  lethal  time  advantage,  and  a  negative  lethal  time 
shows  the  opponent  with  an  advantage. 

The  fourth  metric  is  Tune  on  Offense  (TOF). 

TOF  =  (Gun  time  +  All-aspect  time  +  Tail-aspect  time) 

(D.3) 


ATOF  is  computed  as  Paladin’s  TOF  minus  the  opponent’s  TOF.  A  positive  ATOF  value  shows 
Paladin  with  an  time  on  offense  advantage,  and  a  negative  ATOF  shows  the  opponent  with  a  time 
on  offense  advantage. 


AD-P007  498 


A  TEAMWORK  MODEL  OF  PILOT  AIDING: 

PSYCHOLOGICAL  PRINCIPLES  FOR  MISSION  MANAGEMENT  SYSTEMS  DESIGN 


R.M.  Taylor 
SJ.  Selcon 

RAF  Institute  of  Aviation  Medicine 
Famborough,  Hants.  GU14  6SZ,  UK 


92-16175 

llllllill 


1.  SUMMARY 

Advances  in  automation  and  control/display 
technology  have  enabled  design  effort  to  focus  on 
how  aircrew  system  interfaces  can  be  created  to  help 
perform  the  mission  and  to  help  solve  mission 
problems.  Evidence  of  this  development  towards  a 
concept  of  aiding  the  pilot,  rather  than  replacing 
pilot  functions,  comes  from  recent  systems  proposed 
for  both  ground  and  airborne  mission  control  and 
management.  Interface  design  solutions  for  aircrew 
systems  problems  usually  evolve  pragmatically,  based 
on  considerations  of  convenience,  availability,  utility, 
familiarity  and  operator  acceptance.  Currently, 
there  is  no  substantial  theory  of  the  pilot-aiding 
concept.  In  the  absence  of  a  theoretical  basis,  pilot- 
aiding  interfaces  for  mission  control  and 
management  will  lack  theoretical  consistency  and 
they  will  be  without  any  formal,  systematic 
procedures  for  establishing  design  criteria,  goals  and 
objectives.  Some  of  the  consequences  of  this  will  be 
sub-optimal  utilisation  of  system  function,  loss  of 
situational  awareness,  a  low  level  of  pilot  trust,  and 
failure  to  reduce  pilot  workload.  In  order  to  address 
the  requirements  for  a  theory  of  the  pilot-aiding 
concept,  we  propose  a  model  based  on  the  principles 
of  teamwork,  where  the  human  and  "electronic"  crew 
components  work  co-operatively  towards  achieving 
mission  objectives.  The  teamwork  model  is  derived 
from  the  social  psychology  of  small  group  dynamics, 
from  knowledge  of  human  engineering  requirements, 
and  from  the  need  to  integrate  human  resources 
considerations  in  system  design.  Characteristics  of 
the  model  are  incorporated  into  a  prototype  tool  for 
auditing  the  quality  of  interface  design  solutions  with 
respect  to  teamwork  criteria.  Teamwork  audits  are 
reported  for  several  aircrew  systems,  including  pilot 
aids  for  mission  control  and  management,  in  order  to 
test  the  validity  of  the  model,  and  to  establish  its 
sensitivity  and  diagnostic  power.  Conclusions  are 
drawn  about  interface  design  requirements  affecting 
pilot-aiding  and  mission  performance. 

2.  INTRODUCTION 

Human-Electronic  Crew  teamwork  is  the  co¬ 
ordination  of  activities  of  human  and  machine 
components  of  advanced  crew  systems,  employing 
both  conventional  and  artificial  intelligence 


computational  techniques,  where  there  is  an 
orientation  towards  common  goals  and  objectives. 
Paradigms  and  metaphors,  such  as  Human- 
Electronic  Crew  teamwork,  provide  both  guiding  and 
limiting  frameworks  for  structuring  thinking  about 
crew  systems  interface  design.  Traditionally,  aircrew 
interface  design  has  been  guided  by  the  manual 
control  paradigm,  involving  a  closed-loop  negative 
feedback  control  system,  with  the  human  as  the 
adaptive  element.  Improvements  in  flight  technology 
and  aircraft  capability  revealed  limitations  on  manual 
control  in  IMC/IFR  conditions,  with  the  potential  for 
loss  of  control  in  highly  dynamic  environments, 
unusual  positions  and  high  G.  The  introduction  of 
automation  technology  gave  currency  to  the 
supervisory  control  paradigm,  with  the  transfer  of 
some  human  functionality  to  automation,  and  with 
the  human  operator  allocated  a  system  management 
role.  Experience  has  revealed  the  unreliable  nature 
of  human  monitoring  performance,  with  problems  of 
undetected  degradation,  and  reduced  operator 
intervention  capability.  Now,  the  prospect  of 
utilising  machine  or  artificial  intelligence  (AI)  has 
encouraged  the  use  of  the  problem-solving  paradigm 
for  interface  design.  This  focuses  design  effort  on 
how  the  interface  can  be  created  to  help  perform  the 
mission  (1). 

In  1988  and  1990,  participants  in  two  Joint  GAF/ 
RAF/USAF  Workshops  on  the  Human  Electronic 
Crew  discussed  evidence,  and  broadly  agreed  that 
teamwork  provides  an  appropriate  metaphor  for 
characterising  the  relationship  between  the  human 
and  AI  system  components  needed  to  solve  mission 
problems  (2,3).  In  the  military  aviation  environment, 
mission  problems  are  characterised  by  uncertainty 
and  ill-structure.  They  require  flexibility  in  handling 
contingencies  as  they  arise,  rather  than  as  planned. 

In  dealing  with  this  requirement,  AI  system  interface 
design  needs  to  reduce  operator  workload,  improve 
operator  situational  awareness,  and  enhance 
decision-making  performance  by  creating  an 
improved  integration  or  matching  between  the 
human  and  electronic  crew  capabilities.  The 
difficulties  that  seem  most  likely  to  arise  are  in  the 
areas  of  creating  trust,  maintaining  goals  and  in 
achieving  appropriate  levels  of  autonomy  in  such  a 
teamwork  relationship. 


The  aim  of  this  paper  is  to  develop  an  improved 
understanding  of  the  requirements  for  teamwork  in 
the  Human-Electronic  Crew  with  reference  to  the 
literature  on  social  psychology  and  computer  aiding. 
Through  this  analysis,  it  is  intended  to  identify  key 
dimensions  that  characterise  levels  of  maturity  in 
teamwork,  with  particular  regard  to  problem  solving 
and  decision  making  under  uncertainty.  We  will 
describe  how  these  dimensions  can  be  incorporated 
into  a  prototype  audit  tool  for  evaluating  the  quality 
and  maturity  of  Human-Electronic  Crew  teamwork. 
We  will  then  test  the  validity  of  the  model  by 
applying  the  audit  tool  to  systems  intended  to  aid  the 
pilot  including  aids  for  mission  control  and 
management. 

3.  TEAMWORK  MODEL 

In  order  to  examine  the  requirements  for  Human- 
Electronic  Crew  teamwork,  we  will  be  guided  by  a 
generic  model  representing  the  system  of 
relationships  between  different  aspects  of  teamwork. 
The  model,  initially  proposed  at  the  2nd  Workshop 
on  the  Human  Electronic  Crew  (4),  is  shown  in  Fig. 

1.  This  teamwork  model  is  derived  from  the  social 
psychology  of  small  group  dynamics  (5).  Teams 
differ  from  small  groups  in  the  greater  emphasis 
placed  in  teams  on  clear  definition  of  goals,  roles 
and  structure.  Teams  have  three  distinctive 
characteristics: 

a.  Co-ordination  of  activity,  aimed  at  performing 
certain  tasks  and  at  achieving  specific,  agreed 
goals. 

b.  Well-defined  organisation  and  structure,  with 
members  occupying  specific  roles  with  associated 
power,  authority  and  status,  whilst  exhibiting 
conformity  and  commitment  to  team  norms  and 
goals. 

c.  Communication  and  interaction  between  team 
members,  which  we  refer  to  as  team  processes. 

The  system  of  relationships  between  the  components 
of  teamwork  can  be  understood  in  terms  of  the 
team’s  goals,  resources,  structures,  and  processes, 
and  their  effects  on  individual  team  members,  team 
development  and  team  performance.  Two  system 
feedback  loops  can  be  identified,  namely: 

a.  Feedback  on  performance  of  the  team’s  task 
compared  with  team  goals,  possibly  leading  to 
changes  in  team  resources,  e.g.  recruitment  of 
additional  expertise. 

b.  Feedback  affecting  team  structure  as  both 
individual  members  and  the  team  develop,  learn 
and  adapt  to  changing  goals  and  task  demands,  e.g. 


dynamic  function  allocation,  initiative  turn¬ 
taking,  emergent  leadership. 

Requirements  for  Human-electronic  Crew  teamwork 
can  be  examined  in  relation  to  the  individual 
components  of  this  generic  model.  In  this  analysis, 
each  component  is  addressed  in  two  parts.  Firstly, 
we  present  a  summary  of  relevant  heuristics  and 
guidance  on  teamwork  derived  from  a  selective 
review  of  social  psychology  literature  (6,  7, 8, 9). 
Secondly,  we  identify  some  of  the  principal  issues 
raised  for  Human-Electronic  Crew  teamwork,  based 
on  current  applications  of  decision  support  systems, 
with  relevance  to  the  teamwork  model  components. 


FIGURE  1  -  Teamwork  Model 

4.  TEAM  GOALS 

4.1  Team  Goals:  Social  Heuristics 

Effective  teamwork  is  strongly  associated  with  a 
clear  understanding  by  all  members  of  the  team’s 
performance  objectives.  Effective  teams  are 
characterised  by  a  commitment,  focus  and 
concentration  on  clearly  defined  goals.  Team  goals 
should  be  believed  to  be  worthwhile,  and  personally 
challenging.  Their  pursuit  should  create  a  sense  of 
urgency  and  progress.  Achievement  of  team 
objectives  should  make  a  clear  difference  to  the 
situation.  Failure  of  teamwork  is  most  commonly 
caused  by  the  elevation  of  other  goals,  usually 
personal  or  political,  above  the  team’s  performance 
objectives.  Personal  and  political  agenda  threaten 
the  clarity  of  team  goals,  leading  to  loss  of  focus  and 
reduced  concentration  of  team  efforts.  Achievement 
of  objectives  can  be  facilitated  by  the  setting  of  high, 
but  achievable,  performance  standards,  which 
motivate  and  produce  pressure  on  team  members  to 
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improve  both  individual  and  team  performance. 

4.2  Team  Goals:  Human-Electronic  Crew  Issues 

When  considering  the  design  of  a  goal-based  team 
structure,  it  is  necessary  to  make  the  distinction 
between  goals,  sub-goals,  and  meta-goals.  Goals  are 
the  teams  objective,  successful  attainment  of  which 
are  both  necessary  and  sufficient  for  task 
completion.  Sub-goals  refer  to  the  lesser  objectives, 
attainment  of  which  are  necessary  but  not  sufficient 
for  task  completion.  Sub-goals  are  relevant  where 
achievement  of  mission  goals  requires  a  staged  or 
iterative  process,  with  the  sub-goals  being  the 
objectives  of  each  stage  (10).  Meta-goals  refer  to 
overriding  goals  which,  although  not  being  directly 
related  to  the  task,  provide  an  infrastructure  in  which 
successful  goal  achievement  can  occur.  An  example 
of  a  meta-goal  is  the  maintenance  of  pilot  situational 
awareness  (11).  Although  it  is  not  part  of  the 
mission,  per  se,  it  is  an  important  factor  in  the  pilot’s 
ability  to  reach  task  goals.  Failure  to  achieve  such  a 
meta-goal  will  impact  on  task  performance.  Thus 
meta-goals  are  most  relevant  during  the  design  stage, 
be  it  the  design  of  systems  or  team  structures. 

When  team  structures  are  functioning  in  a  dynamic 
environment,  then  sub-goals  (and  to  a  lesser  extent 
task  goals)  will  change  (12).  For  effective  team 
performance,  all  team  members  must  be  aware  of 
any  change  in  their  goals.  Failure  to  communicate 
such  changes  will  result  in  the  loss  of  the  common 
goal  structure.  The  impact  of  this  for  the  design  of 
human-computer  teams  is  that  such  communications 
must  be  bidirectional,  i.e.  sufficient  feedback  must  be 
given  by  both  team  members  for  the  other  to 
maintain  his  awareness  of  the  new  goals. 

S.  TEAM  RESOURCES 

S.l  Team  Resources:  Social  Heuristics 

Team  resources  comprise  all  the  relevant  abilities 
and  tools,  skills,  rules  and  lmowiedge  available  to 
perform  the  task,  including  both  human  and  machine 
capabilities.  The  availability  of  resources  is 
determined  by  the  team  size,  i.e.  the  number  of 
individual  members,  by  the  level  of  individual  and 
team  training,  competence  and  expertise,  and  by 
situational  factors  such  as  fatigue,  boredom  and 
anxiety  stress.  Increasing  team  size  may  facilitate  or 
inhibit  performance  on  tasks,  e.g.  by  generating  more 
ideas  on  problem  solving  tasks,  whilst  increasing  the 
time  taken  to  generate  each  idea.  Resources  may  be 
redundant  or  unique,  through  the  team  being 
composed  of  homogeneous  or  heterogeneous 
membership.  Homogcniety  for  some  resources  may 
be  more  effective  for  performance  than 
heterogeneity.  However,  resource  variability, 


through  heterogeneity  may  produce  greater 
sensitivity  to  changing  task  demands.  The  resources 
must  be  willing  and  able  to  collaborate  effectively. 
Compatibility  can  be  achieved  with  different  but 
complementary  resources  for  dimensions  such  as  the 
need  to  dominate  or  to  control  events.  Teamwork  is 
normally  associated  with  the  achievement  of  specific 
goals  requiring  specialised  skills.  For  effective 
teamwork,  the  requisite  resources  should  be 
available  and  appropriately  distributed  among  the 
team  members,  in  accordance  with  the  task  structure 
and  load.  In  tasks  where  the  performance  of  a  team 
is  limited  by  the  weakest  member  (conjunctive  task 
constraints),  resource  variability  is  undesirable.  In 
tasks  where  team  performance  is  determined 
completely  by  the  best  member’s  performance 
(disjunctive  task  constraints),  a  high  degree  of 
resource  variability  is  desirable.  Matching  of 
resource  characteristics  to  task  demands,  in  terms  of 
the  difficulty  of  underlying  operations,  is  the  key  to 
estimating  the  capability  for  effective  teamwork. 

52  Team  Resources:  Human-Electronic  Crew  Issues 

The  design  of  the  human-computer  team  requires 
that  knowledge  be  gained  of  the  resources  of  each  . 
team  member.  This  will  allow  the  a  priori  allocation 
of  tasks  to  that  member  best  fitted  to  perform  them 
(where  expertise  is  limited  to  one  member)  or 
dynamically  according  to  the  situational  demands 
(where  both  men'  -rs  have  relevant  expertise) 
Correct  utilisation  of  unique  and  redundant 
resources  will  produce  a  synergistic  team,  thus 
extending  the  total  resources  of  the  team  (13).  An 
example  where  unique  resource  allocation  would  be 
effective  is  in  judgments  under  uncertainty.  Humans 
are  traditionally  poor  at  integrating  multiple  sources 
of  probabilistic  information  in  a  formal  statistical 
manner  (14).  Computers  are,  on  the  other  hand, 
good  at  such  ’number  crunching’  activities.  Thus  a 
successful  team  would  use  the  computer  resource  to 
achieve  this  part  of  the  process.  Humans  are  good, 
however,  at  accepting  integrated  advice  and  using 
heuristics  to  make  judgments  under  uncertainty  (15). 
Thus  the  team  would  use  this  human  resource  to 
complete  the  decision  process. 

Where  both  team  members  have  the  expertise  and 
resources  to  perform  a  function,  then  allocation  of 
that  function  should  be  performed  dynamically,  with 
the  choice  of  who  should  do  the  task  being  decided 
through  consideration  of  meta-goals,  e.g. 
maintenance  of  SA,  reduction  of  pilot  workload  etc. 

Another  consideration  in  the  integration  of  human 
and  computer  resources  to  provide  enhanced  goal 
attainment,  is  in  the  method  of  representation  of  task 
information  by  each  party,  such  that  a  synergistic 
relationship  can  be  attained.  Triggs  (16)  showed 


that  the  ability  of  human  decision  makers  to 
integrate  multiple  sources  of  probabilistic 
information  was  dependent,  not  just  on  the  difficulty 
of  the  task,  but  also  on  the  method  of  information 
representation  used  in  the  task.  Further,  Green  (17) 
claims  the  knowledge  structures  of  experts  and 
novices  differ  in  their  organisation  and  hence  the 
utilisation  of  such  resources  within  a  human- 
electronic  crew  will  require  that  such  differences  be 
taken  into  account  by  system  designers.  Thus,  the 
design  of  suitable  task  structures  to  exploit  the 
available  resources  will  be  critical  in  for  the 
successful  integration  of  human-electronic  crew 
teams.  Some  issues  relevant  to  the  design  of  these 
systems  are  discussed  below. 

Operator  capability  analysis  is  a  key  technology  for 
matching  human  resource  capabilities  to  mission 
performance  objectives  (18).  This  analysis  needs  to 
be  extended  to  encompass  both  human  and 
electronic  crew  capabilities.  A  common 
performance  resource  model  and  associated 
taxonomy  is  required  for  systematically  linking 
resource  capabilities  to  task  demands,  including 
engineering,  aptitude  and  training  parameters  of 
both  the  human  and  electronic  crew  team 
components. 

6.  TEAM  STRUCTURE 

6.1  Team  Structure:  Social  Heuristics 

Team  structure  concerns  the  relatively  stable  pattern 
of  relationships  between  members  that  determines 
the  communication  required  for  co-ordination  of 
activities,  and  that  governs  the  distribution  of 
function^,  roles,  status  and  power.  The  function  of 
team  structure  is  to  implement  access  to  task- 
relevant  resources.  Team  structure  and  associated 
patterns  of  communications  should  be  designed  to 
facilitate  rather  than  restrict  access.  Effective 
teamwork  requires  a  structure  driven  by 
performance  results.  The  required  structure  is  that 
which  is  appropriate  for  achievement  of  the  specific 
team  performance  objectives,  with  the  minimum 
complexity  of  resources  necessary  and  sufficient  for 
successful  functioning.  Maintenance  of 
organisational  processes  should  not  consume 
unnecessary  resources.  In  a  functionally  effective 
structure,  individual  and  team  efforts  always  lead 
towards  achievement  of  the  team  goal.  Increasing 
cohesiveness  and  attraction  between  team 
participants  leads  to  greater  conformity  to  team 
norms,  more  uniformity  of  behaviour,  improved 
performance  and  increased  job  satisfaction.  Poor 
performance  and  morale  are  associated  with  poor 
cohesiveness  and  low  membership  attractiveness. 
Centralisation  of  communication  structure  affects 
membership  satisfaction  and  team  performance. 


More  centralised  communication  networks  (e.g. 
wheel  versus  circle  structure;  produce  better  team 
performance  but  lower  membership  satisfaction, 
except  in  complex  tasks  when  the  central  elements 
become  overloaded.  Decentralised  networks  allow  a 
more  even  distribution  of  workload  (Fig.  2). 
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FIGURE  2  -  Team  Communication  Structures 

Structure  creates  role  differentiation.  Status  and 
power  are  affected  by  roles  and  functions. 
Discrepancy  between  the  expected  role,  perceived 
role  and  enacted  role  of  individuals  introduces 
conflict  between  team  members.  The  evaluation 
attached  to  a  role  determines  the  status  of  the 
individual  and  influences  conformity  to  team  norms. 
The  perception  that  interactants  have  equal  status 
facilitates  communication.  Function  allocation  is 
essential  for  effective  co-ordination  of  goal-oriented 
activities.  A  high  degree  of  rigidity  and  clarity  in 
function  allocation,  with  clear  accountabilities,  is 
beneficial  for  well-structured  tasks,  which  follow  a 
clearly  defined  plan,  and  for  tasks  requiring  unique 
rather  than  redundant  resources.  Flexibility  in 
function  allocation  is  beneficial  for  tasks  involving  ill- 
structured  problems,  uncertainty  and  requiring  good 
communication  between  team  members.  The 
communication  structure  influences  the  distribution 


of  information,  power  and  authority  in  teams.  The 
member  through  which  most  information  passes  has 
the  potential  to  exert  considerable  influence  over  the 
team  (informational  power).  In  a  highly-centralised 
communication  structure,  the  member  in  the  central 
role  acts  as  the  information  gate-keeper.  This 
member  is  most  likely  to  be  perceived  as,  and  act  as 
the  t.’am  leader.  The  distribution  and  locus  of  power 
depends  on  their  ability  to  monitor  the  performance 
of  members  and  to  exercise  reward,  coercion  and 
feedback  (reward  and  coercive  power),  to  generate  a 
positive  image  that  attracts  emulation  (referent 
power)  and  by  the  ability  to  internalise  goal-relevant 
information  and  acquire  knowledge  (expert  power). 
Effective  teamwork  is  most  likely  to  occur  when 
assigned,  legitimate  power  coincides  with  the  locus 
of  informational,  expert,  referent,  reward  and 
coercive  power.  The  function  of  the  team  leader  is 
to  exercise  authority  and  power  in  order  to  achieve 
the  team’s  performance  objective.  Leadership  is 
achieved  by  changing,  directing  and  controlling  the 
behaviour,  attitudes  and  opinions  of  team  members 
to  conform  with  team  roles,  standards,  norms,  and 
goals.  Leadership  behaviour  includes  clarifying  team 
objectives,  making  important  decisions  and  taking 
initiatives,  and  identifying  ways  of  achieving 
objectives.  Leadership  effectiveness  is  dependent  on 
the  exercising  of  situationally  appropriate  task- 
oriented  and  relationship-oriented  skills.  A  strongly 
authoritarian,  task-oriented  style  is  not  necessarily 
the  most  productive  when  dealing  with  ill-structured 
tasks  requiring  good  communication  and 
cohesiveness  between  members. 
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The  implementation  of  the  structures  described 
above  in  the  human-computer  team  require 
consideration  of  the  levels  of  autonomy  to  be 
assigned  to  the  computer’s  funcdons.  Figure  3  shows 
a  graphic  conceptualisation  of  two  alternative  team 
structures,  with  the  electronic  crew  member  in  a 
subordinate  (tandem)  and  in  associate  (side-by-side) 
roles.  Several  taxonomies  of  the  levels  of  autonomy 
of  human-computer  interaction  have  been  postulated 
(19,20,21).  Sheridan  et  al  (19)  describe  the  level  of 
interaction  as  varying  from  the  human  performing  all 
functions,  through  increasing  levels  of  computer 
autonomy,  to  the  computer  performing  functions 
independently  with  discretionary  power  to  not 
inform  the  human.  As  the  computer  assumes  more 
responsibility,  then  its  role  changes.  They 
characterise  these  roles  as  ’tool’,  ’assistant’,  and 
’autonomous  agent’  with  respect  to  their  increasing 
autonomy.  Although  it  may  be  argued  that  more 
levels  could  be  included  in  the  model,  it  does  provide 
a  useful  metric  against  which  to  measure  the 
maturity  of  currently  available  systems,  as  well  as  an 
a  priori  design  aid  in  the  development  of  such 


systems.  In  other  words,  such  a  taxonomy  allows  you 
to  choose  the  level  of  interaction  that  you  judge  to  be 
more  relevant  for  a  particular  task,  and  then  to  judge 
existing  systems  against  that  to  see  how  closely  the 
design  aim  has  been  approached.  The  level  chosen  is 
likely  :r>  be  situadonally  dependent  in  that  it  will 
depend  on  the  demands  of  both  goals  and  meta¬ 
goals.  This  is  since  the  requirement  for  autonomy  is 
itself  a  dynamic  function  of  the  operational  context. 


FIGURE  3  -  Human  Electronic  Cre.»  Structures 

For  efficient  teamwork,  the  locus  of  power  should  be 
allocated  to  maximise  goal  achievement.  An  example 
would  be  the  computer  taking  control  when  the  pilot 
suffers  G-induced  loss  of  consciousness.  Also,  where 
the  computer  controls  data  fusion  and  displays 
management,  e.g.  Pilot’s  Associate,  and  hence 
information  flow,  then  this  necessitates,  by  implied 
consent,  that  at  least  part  of  the  leadership  role 
(traditionally  associated  with  the  human  team 
member)  will  be  performed  by  the  computer  team 
member.  A  limit  on  the  autonomy  of  the  machine 
element  of  the  team  is  also  likely  to  be  imposed  by 
the  available  knowledge  state  of  the  machine. 
Zachary  et  al  (22)  classify  decision  situations 
according  to  how  many  of  the  following  elements  of 
the  decision  are  known. 

a.  Goals:  desired  states  against  which  outcomes  are 
matched. 

b.  Knowledge:  representation  of  relevant  real-world 
information. 

c.  Action  Options:  legal  operators  that  can  be  used 
to  alter  the  situation. 


d.  Action  Outcomes:  states  resulting  from  action 
options. 

e.  Desirability  Functions:  how  well  do  outcomes 
satisfy  goals. 

They  argue  that  full  automation  of  decisions  is  only 
appropriate  when  all  or  nearly  ail  of  these  elements 
are  known.  When  knowledge  is  lacking,  i.e. 
uncertainty  exists,  then  supporting  the  human 
decision  maker  is  relevant. 

Figure  4  shows  the  communication  structure 
proposed  for  the  six  major  sub-systems  comprising 
the  Pilot’s  Associate  (23).  The  executive  sub-system 
was  originally  conceived  as  an  overall  executive 
manager,  residing  between  the  individual  sub-system 
experts  with  responsibility  for  co-ordinating  their 
actions.  Subsequently,  doubts  have  arisen  over  the 
need  for  this  separate  executive  function,  in  addition 


PA  Modules  Key: 

1.  Mission  Executive/Manager 

2.  Situation  Assessment 

3.  Tactics  Planner 

4.  Systems  Status 

5.  Mission  Planner 

6.  Pilot  Vehicle  Interface 
P.  Pilot 

FIGURE  4  -  Pilot  Associate  Communication 
Structure 

to  the  Pilot  Vehicle  Interface  (PVI)  manager  expert 
(3).  Deletion  of  this  separate  executive  function 
could  equate  to  the  loss  of  a  redundant  layer  of 
bureaucracy  in  order  to  facilitate  access  to  primary 
resources. 

Where  task  allocation  is  static,  the  level  of 
interaction  can  be  chosen  a  priori.  Dynamic  task 
allocation  may  require  a  variable  authority  gradient 


to  exist  in  order  to  best  exploit  the  resource 
distribution  across  team  members.  Where 
situational  demands  are  high,  requiring  pilot 
mandate  for  all  low  level  ’chores’  may  decrease  the 
usefulness  of  assigning  such  tasks  to  the  computer. 
When  the  demand  is  less,  then  less  autonomy  may  be 
beneficial  by  maximising  the  degree  to  which  the 
pilot  is  ’in  the  loop’.  The  extent  to  which  this  is 
relevant  is  likely  to  depend  on  the  types  of  functions 
which  the  computer  can  perform,  and  also  on  the 
degree  of  trust  in  the  computer  exhibited  by  the 
human.  Where  a  high  degree  of  trust  is  available, 
task  leadership  functions  may  be  shared  or  even 
transferred  to  the  computer  member.  How  such 
levels  of  trust  can  be  produced  are  discussed  in  the 
next  section.  Thus  the  level  of  interaction  chosen, 
and  hence  the  most  appropriate  team  structure,  will 
be  dependent  on  the  task  being  performed, 
knowledge  of  the  task  elements  available  to  each 
part  of  the  team,  the  requirement  for  workload 
reduction/SA  maintenance,  the  humans  trust  in  the 
machine’s  ability,  the  need  to  keep  the  pilot  ’in  the 
loop’,  the  efficiency  of  the  man-machine 
communication,  and  knowledge  of  what  the  other 
member  is  doing. 

7.  TEAM  PROCESSES 

7.1  Team  Processes:  Social  Heuristics 

Team  processes  of  communication  and  interaction 
are  affected  by  the  structural  characteristics  of  the 
team  (roles,  status,  cohesiveness).  Communications 
can  be  analysed  for  functional  content  and  style. 
Content  can  be  task  oriented  or  social-emotional 
oriented.  Task-oriented  communication  includes 
interactions  exchanging  information  (repetition, 
confirmation,  clarification),  opinions  (evaluation, 
analysis,  feelings)  and  direction  (suggestions, 
possible  actions).  Communication  with  social- 
emotional  orientation  involves  positive  and  negative 
reactions  concerning  agreement  (acceptance, 
concurrence,  understanding),  satisfaction  (release  of 
tension,  humour)  and  solidarity  (affirmation  of 
status,  help,  reward).  Social  cohesiveness  is 
important  for  team  productivity  and  performance. 
Interactive  styles  can  be  characterised  as  affiliauve- 
nonaffiliative,  affecting  cohesiveness  and  reflecting 
attractiveness;  dominant-submissive,  reinforcing 
power  relationship  and  reflecting  status;  responsive- 
unresponsive,  reflecting  the  expressive  quality  and 
effectiveness  of  communication. 

Communication  has  temporal  and  bandwidth 
constraints  (channels,  modalities).  Unrestricted 
communication  can  be  unproductive,  distracting  and 
an  inefficient  utilisation  of  resources.  Broadening 
the  communication  bandwidth  increases  the 
psychological  closeness  of  interactants.  However, 
some  psychological  distance  may  be  necessary  for 
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tasks  requiring  autonomy  and  independence  of 
thought  and  action.  Widening  the  bandwidth  beyond 
that  needed  for  audio  communication  does  not 
improve  performance  on  some  problem-solving 
tasks.  The  communication  bandwidth  should  be  that 
which  is  necessary  and  sufficient  for  achievement  of 
team  goals.  Formal  language  can  be  restrictive,  slow 
and  inefficient  for  solving  ill-structured  problems. 
Conformity  to  dialogue  protocols  (e.g.  rules  for 
structuring  turn-taking,  transferring  controls)  should 
increase  the  efficiency  of  communication  and 
maintain  the  goal-orientation  of  interactions. 

Effective  communication  requires  knowledge  of  the 
functionality,  meaning  and  goal  of  the 
communication.  This  is  achieved  by  tracking  both 
the  goal  and  the  context  of  the  communication,  using 
domain-specific  information  and  information  for  the 
control  of  the  communication  process. 

Effectively  communicating  and  collaborating  teams 
are  characterised  by  a  high  degree  of  trust.  Trust 
requires  predictability,  dependability  and  faith  in 
interpersonal  relationships.  Trust  occurs  in  a 
collaborative  climate  characterised  by  honesty, 
openness,  consistency  and  respect.  Violations  of 
trust  have  catastrophic,  irredeemable  effects  on  team 
functioning  and  performance.  Full  teamwork 
potential  is  unlikely  to  be  realised  when  trust  has 
been  broken.  Trust  allows  team  members  to  stay 
problem-focused,  it  promotes  efficient 
communication  and  co-ordination,  improves  the 
quality  of  collaborative  outcomes,  and  it  leads  to 
compensatory  behaviour.  Compensation  between 
individuals  is  necessary  for  performance  standards  to 
be  independent  of  variability  in  team  resources. 
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Communication  between  the  human  and  computer 
team  members  is  achieved  through  the  design  of  the 
interface  between  them.  An  effective  interface 
requires  an  understanding  of  the  knowledge 
requirements  of  the  team  members  with  a 
consequent  moding  of  input/output  facilities  to 
support  these  requirements.  Again,  both  goals  and 
meta-goals  need  to  be  considered  in  the  design  of 
the  interface.  If  the  computer  is  to  control  the  flow 
of  information,  then  an  efficient  model  of  the 
human’s  information  processing  abilities/ 
requirements  is  essential.  Adaptive  or  learning 
interfaces  have  the  potential  for  maximising 
teamwork  (24).  The  problem  with  such  systems  in 
that  they  can  learn  ’bad  habits’  (or  sub-optimal 
behaviours)  from  the  human  if  they  are  adapting  to 
his  behaviour  without  sufficient  reference  to  the  task 
and  meta-goals.  They  need  to  be  goal  rather  than 
behaviour  driven,  implying  the  need  for  the 
adaptivity  to  be  bidirectional.  In  other  words,  the 
team  efficiency  will  only  be  improved  where  human 


and  computer  are  given  sufficient  feedback  on  goal 
achievement  to  both  learn,  and  hence  improve  sub- 
optimal  performance. 

An  alternative  approach  is  to  embed  in  the  system 
sufficient  knowledge  to  allow  it  to  make  a  priori 
judgments  of  the  operator’s  knowledge  requirements 
and  to  structure  the  interface  accordingly.  An 
example  of  such  an  interface  is  the  Pilot  Vehicle 
Interface  (PVI)  described  by  Shelnutt  (25, 26).  The 
PVI  employs  an  expert  system  containing  knowledge 
about  goals,  actions  available  etc,  and  supports  the 
integration  of  the  operator  with  both  his  expert  and 
non-expert  systems  by  providing  dynamic  sensor- 
and  information-fused  displays.  The  embedded 
knowledge  it  contains  allows  it  to  mode  these 
displays  to  be  relevant  to  the  task  being  performed 
by  the  operator,  thus  giving  him  the  information  he 
needs  when  he  needs  it.  The  advantage  of  this  type 
of  approach  is  that  it  ensures  that  common  goals  and 
knowledge  exist  between  human  and  machine,  and 
that  such  goals  may  be  maintained  even  in  dynamic 
situation. 

Such  goal  tracking  and  commonality  will  not  only 
allow  compensatory  team  work  to  occur,  but  will  also 
enable  a  suitable  level  of  trust  to  develop  and  be 
maintained.  Failure  to  provide  it  may  result  in  over¬ 
trusting  (27)  or  under-trusting  (28,29),  both  of  which 
impact  negatively  on  task  goal  achievement  (30). 
Eimer  investigated  the  effectiveness  of  a  decision 
support  system  (DSS)  in  a  command,  control,  and 
communications  task  involving  uncertainty.  He 
simulated  decision  support  (which  could  be  either  of 
human  or  machine  origin)  of  varying  accuracy  (i.e. 
how  often  their  advice  was  correct)  to  examine  the 
relationship  between  operator  performance  and  DSS 
performance.  Further,  he  investigated  the  effect  on 
operator  performance  of  the  system  breaking  down, 
i.e.  providing  invalid  advice  continuously.  He  found 
that  operator  performance  decreased  as  the 
effectiveness  of  the  DSS  decreased.  Where  DSS 
accuracy  was  low,  then  it  produced  worse 
performance  in  subjects  than  the  control  group  with 
no  DSS.  When  a  previously  valid  DSS  became 
invalid,  then  performance  again  became  worse  than 
that  of  the  control  group.  In  other  words,  overtrust 
in  an  inaccurate  system,  or  one  which  ceases  to 
function,  interferes  with  the  task  and  produces  worse 
performance  than  no  system  at  all. 

A  lack  of  trust  is  liable  to  result  in  a  boy  who  cried 
wolf  situation,  where  teamwork  will  break  down  due 
to  a  judgment  of  machine  generated  information  as 
being  unreliable  and  hence  untrustworthy.  This  will 
result  in  either  the  pilot  ignoring  the  information  or 
seeking  to  check  it  for  himself.  Either  of  these 
outcomes  is  liable  to  produce  sub-optimal  teamwork. 
This  is  supported  by  an  experimental  investigation 


into  the  effect  of  trust  on  a  discussion  support  system 
reported  by  Lerch  and  Prietula  (28).  They  measured 
subjects  agreement  and  confidence  in  human  and 
expert  system  generated  advice.  They  found  that 
initially  trust  increased  rapidly  as  correct  advice  was 
given.  Following  a  trial  where  incorrect  advice  was 
given,  however,  confidence  was  significantly 
decreased  on  future  trials  and  failed  to  return  to  the 
level  achieved  before  the  incorrect  advice  trial.  Thus 
it  seems  likely  that  any  system  with  low  accuracy  is 
likely  to  be  considered  as  untrustworthy  by  the 
human,  and  hence  the  interaction  between  them  will 
be  degraded. 

Taylor  (31)  attempted  to  quantify  the  trust  required 
between  a  human-machine  crew  by  measuring  the 
factors  affecting  trust  between  two-man  human 
teams  (pilots  and  navigators).  He  differentiated 
between  factors  affecting  the  demand  for  trust  and 
those  affecting  the  supply  of  trust.  Unless  the  two 
are  matched,  then  optimum  team  co-operation  will 
not  be  achieved.  Each,  he  says,  can  be  manipulated 
to  improve  trust  within  the  team.  Demand  for  trust 
can  be  reduced  by  minimising  the  risk  and  negative 
payoffs  associated  with  incorrect  decisions,  and  also 
by  ensuring  that  a  common  goal/intent  structure 
exists  and  is  consistently  applied.  The  supply  of  trust 
can  be  improved  by  the  machine  reducing  the 
uncertainty  associated  with  decisions  thus  increasing 
the  probability  of  success  in  them  and  hence  the 
pilot’s  confidence  in  those  decisions.  Further,  by 
representing  that  uncertainty  to  the  pilot  (rather  than 
removing  it),  it  provides  a  degree  of  transparency  to 
the  system,  allowing  the  human  to  understand,  and 
hence  trust  the  machine  advice  more  readily. 

8.  TEAMWORK  MATURITY  AUDIT 

8.1  Audit  Objectives 

On  the  basis  of  the  forgoing  analysis,  assuming  that 
the  teamwork  model  is  valid,  it  should  be  possible  to 
create  tools  for  evaluating  and  auditing  the  quality 
and  maturity  of  teamwork  in  candidate  Human- 
Electronic  Crew  systems.  Information  gained  from 
audits  could  serve  to  guide  future  developments 
aimed  at  improving  system  teamwork  performance. 
Audit  information  could  also  serve  to  assess  the 
validity  of  the  teamwork  model  and  to  test  the 
model’s  sensitivity  and  diagnostic  power. 

8.2  Audit  Constructs 

A  selection  of  possible  audit  constructs,  associated 
with  teamwork  maturity,  linked  to  the  principal 
model  components,  is  shown  in  Table  1.  Additional 
constructs  from  other  domains,  e.g.  systems 
architecture,  software  engineering  etc  will  need  to  be 
included  in  a  fully  comprehensive  analysis.  The  level 


of  teamwork  maturity  in  Human-Electronic  Crews 
could  be  assessed  by  establishing  the  strength  of 
teamwork  constructs  in  the  candidate  systems, 
judged  by  appropriate  experts,  such  as  system 
designers,  or  preferably,  system  users.  A  simplified 
method  might  establish  the  extent  to  which  the 
constructs  are  judged  to  be,  say,  primary  features, 
minor  features,  or  not  represented  in  the  system. 
Alternatively,  the  strength  of  the  constructs  could  be 
measured  using  questionnaires,  rating  scales, 
repertory  grids,  or  other  subjective  measurement 
techniques.  A  test  of  the  validity  of  the  teamwork 
model  could  be  achieved  by  measuring  the  extent  to 
which  the  derivative  audit  tools  are  sensitive  to 
changes  in  pilot-aiding  systems  using  old  (immature) 
and  new  (relatively  mature)  technology,  and  that 
they  can  discriminate  the  causes  of  differences  in 
mission  performance. 

83  Audit  Candidates 

In  order  to  provide  some  preliminary  worked 
examples  for  discussion,  and  so  as  to  address  some 
of  the  validity  issues,  sample  teamwork  audits  have 
been  conducted,  using  the  prototype  audit 
constructs,  on  eight  candidate  systems,  designed  for 
different  operational  roles,  with  both  immature  and 
advanced  technology.  Short  technical  descriptions  of 
the  audited  systems  are  provided  below. 

8 3.1.  Civil  Transport  Role 

a.  Immature  Candidate  -  Piper  Apache  PA28/7 

Mid-1950’s,  twin  piston  mono-plane,  with 
retractable  gear,  constant  speed  propellers, 
split  flaps,  full  anti-icing  kit;  a  nominal  4-seater 
with  dual-controls  and  standard  blind  flying 
panel,  designed  for  single-pilot  operation,  used 
for  instrument  training  and  air  taxi. 

b.  Mature  Candidate  -  A320  AIRBUS 

Mid  1980’s,  advanced  state-of-the-art  twin  jet, 
medium  range  passenger  aircraft,  designed  for 
2-pilot  operation,  with  glass  cockpit,  fly-by-wire 
and  side-stick  controllers,  full  FMS,  integrated 
instrument  presentation,  auto  throttle  and  auto 
pilot.  FMS  is  loaded  by  computer  disc  and 
instrument  specialist. 


MATURITY  CONSTRUCTS 

DEFINITIONS 

TEAM  GOAL 

Clarity 

Common  Structure. 

Tracking 

Impact 

Achievement 

TEAM  RESOURCES 

Clearly  defined  performance  objectives. 
Shared  understanding  of  meta/sub  goals. 
Awareness  of  changing  objectives. 

Critical  for  mission  success. 

High  probability  of  success. 

Sufficiency 

Availability 

Heterogeneity 

Compatibility 

Enhancement  Capability 

TEAM  STRUCTURE 

Enough  expertise/ability/competence. 
Readiness  for  application  to  task. 
Variability/uniqueness  of  expertise. 

Ability  to  combine/integrate/match. 

Ability  to  add  to  expertise. 

Goal  Driven 

Resource  Accessibility 

Cohesiveness 

Dynamic  Function  Allocation 

Levels  of  Autonomy 

TEAM  PROCESSES 

Governed  by  performance  objectives. 
Facilitates  access  to  resources. 

Attracts  conformity  to  team  norms. 
Real-time  role-task  distribution. 

Degrees  of  independent  functioning. 

Wide  Bandwidth 

Bidirectionality 

Shared  Initiative 

Common  Knowledge  Base 

Trust 

Multiple  modalities  for  communication. 
Two-way  flow  of  information/feedback. 
Leadership  turn  taking. 

Shared  understanding  of  situations. 

Willing  to  accept  others’  judgments. 

TABLE  1  -  Prototype  Teamwork  Audit  Tool 


83.2  Air  Defence  Role  833  Strike  Attack  Role 

a.  Immature  Candidate  -  BAe  Hawk  a.  Immature  Candidate  -  Panavia  Tornado  GR1 

Mid  1970’s,  two-seat  tandem,  rugged,  agile  jet.  Late  1970’s,  variable  geometry  (swing  wing), 

with  commercial  cockpit  instruments  and  flight  two-seat  tandem,  multi-role  jet,  employed  in  the 

controls,  designed  as  an  advanced,  tactical  overland  strike/attack  and  reconnaissance  roles, 

weapons  trainer  for  fast-jet  pilots,  and  with  all-weather,  night  automatic  Terrain 

employed  in  a  secondary  air  defence  war  role.  Following,  Inertial  and  Doppler  navigation 

radar;  with  pilot  E-scope  and  moving  map 

b.  Mature  Candidate  -  General  Dynamics  F16C  display,  automatic  laser/radar  or  laser/HUD 

Fighting  Falcon  weapon  aiming  and  delivery,  ECM  radar 

warning;  and  with  navigator  combined  Radar 
Late  1970’s  multi-role  single-seat,  high  and  Projected  Map  Display,  Electronic  digital 

manoeuvrability,  light-weight  fighter  jet,  TV  tabular  displays  for  mission  computer 

updated  with  advanced  air-to-air  combat  and  monitoring  and  planning,  and  with  mission  plan 

air-to-ground  capabilities,  with  fly-by-wire  side-  pre-loading  facility, 

stick  controller,  advanced  digital  avionics, 

radar,  and  weapons  delivery  systems,  low  b.  Mature  Candidate  -  Mission  Management  Aid 

altitude,  Infra-red  LANTIRN  night  attack,  (MMA)  UK  MOD/Industry  Joint  Venture 

automatic  electronic  jammer,  threat  analysis 

and  voice  warning  system.  Collaborative  research  project  aimed  at 

establishing  functional  requirements  and 
prototyping  a  system  to  aid  single-seat  jet 
mission  management  in  Air-to-Ground  role, 
with  future  Air-to-Air  enhancement  capability. 
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Sensor  Fusion,  Situation  Assessment,  Dynamic 
Planning,  and  Man-Machine  Interface  core 
functions  generating  a  tactical  plan  for  pilot 
acceptance/rejection,  presented  through  the 
pilot  controls/displays,  including  current 
situation  information,  proposed  MMA 
action/solutions/explanations,  systems  status 
and  cueing,  and  automatic  information 
prioritisation/scheduling  compatible  with  the 
pilots  current  tasks  and  mission  objectives. 

8J.4  Ground  Planning  Role 

a.  Immature  Candidate  -  Jaguar  Mk  1  Aircraft, 
Ferranti  Autoplan 

Mid  1970’s  digital  aircraft  route  planning 
system  for  the  Jaguar  Mk  1  tactical  strike  and 
ground  attack  aircraft,  for  use  in  conjunction 
with  standard  air  charts,  comprising  digitised 
chart  plotting  table,  cursor  for  positional  data 
inputs,  electronics  unit,  paper  tape  printer  and 
control  panel,  with  outputs  of  track,  fuel,  time 
etc  to  25  metres  accuracy  on  a  1:50K  chart,  and 
with  a  Portable  Data  Store  for  automatic 
transfer  to  the  aircraft’s  digital  navigational 
system. 

b.  Mature  Candidate  -  Harrier  GR  Mk  7  Aircraft 
Advanced  Mission  Planning  Ad  (AMP A) 

Currently  under  UK  MOD  procurement,  an 
Advanced  Mission  Planning  Ad  (AMP A)  to 
provide  computer  assistance  for  ground  mission 
planning  of  Harrier  GR  Mk  7  close-air  support, 
interdiction,  counter  air  and  recce  operations 
and  training.  Employing  advanced,  state-of-art 
networked,  computer-based  mission  planning 
workstations  using  from  raster  scanned,  and 
eventually  digital  vector  map  data,  with  high 
resolution  colour  map  image  display,  overlays, 
panning,  zooming  and  pointing  facilities,  full 
graphics  package,  manual  and  automatic  route 
planning,  calculation  and  editing  aids,  3-D 
route  visualisation  simulation  and  intervisibility 
plan,  grey  scale  image  handling,  and  hard  copy 
and  electronic  aircraft  outputs. 

8.4  Audit  Method 

Understanding  and  communication  of  the  meaning 
of  the  teamwork  audit  constructs  are  likely  to  be 
sources  of  variation  in  audit  results.  To  minimise 
these  principal  sources  of  variation,  and  to  simplify 
the  task  in  hand,  a  single  system  expert  was  sought 
for  each  of  the  four  roles.  This  was  achieved,  with 
one  exception.  In  the  air  defence  role,  two  experts 
co-operated  to  provide  a  joint  assessment.  The  Civil 
Transport  Role  audit  was  provided  by  Capt  Paul 


Wilson,  Head  of  CHIRP  Group,  Psychology 
Division,  RAF  LAM,  Civil  Pilot  and  Aviation 
Consultant  to  the  CAA.  The  Air  Defence  Role  audit 
was  provided  by  Lt  Col  (USAF)  Geoff  McCarthy 
and  Sqn  Ldr  Terry  Adcock,  RAF  LAM  Medical 
Officer  Pilot  and  Test  Pilot,  respectively.  The 
Strike/Attack  Role  audit  was  provided  by  Sqn  Ldr 
Phil  Price,  OR  52c(Air)  MOD,  a  Tornado  Pilot, 
currendy  responsible  for  advanced  cockpit 
operadonal  requirements.  The  Ground  Planning 
Role  audit  was  provided  by  Sqn  Ldr  J.WJ.  (Ted) 
Taylor  AES  11,  MOD(PE) ,  an  RAF  Navigator 
currently  responsible  for  the  procurement  of  mission 
planning  systems. 

These  5  experts  provided  the  audit  data  for  both  the 
immature  and  mature  candidates  within  their 
respecdve  roles.  Following  briefing  on  the  purpose 
and  scope  of  the  teamwork  model  and  task,  and  two 
candidate  system  were  evaluated  with  regard  to  the 
20  teamwork  constructs,  based  on  a  common,  agreed 
understanding  of  the  construct  meaning. 

In  each  case,  the  expert(s)  were  required  to  decide 
whether  each  audit  construct  was  a  primary  feature 
(Score  =  2),  a  minor  feature  (Score  1)  or  not, 
represented  in  the  system  (Score  =  0). 

8.5  Audit  Results 

The  results  of  the  audit  are  summarised  in  Table  2 
and  displayed  graphically  in  Fig  5.  There  is 
insufficient  data  points  to  conduct  a  reliable, 
meaningful  statistical  analysis.  The  maximum 
possible  score  is  10  for  each  of  the  model 
components,  and  40  overall.  The  assigned  scores 
ranged  widely  from  1710  (Autoplan:  Processes)  to 
10/10  (A320:  Goals;  GR  1;  Goals,  Processes)  within 
components,  and  from  10/40  (Autoplan)  to  36/40 
(GR  1)  across  components.  With  the  exception  of 
the  Strike/Attack  Role,  the  hypothesised  "Immature" 
Candidates  scored  less  in  total  and  less  within 
components  (N.B.  one  equal)  that  the  comparable 
Mature  Candidates.  The  Tornado  GR  1,  was 
assigned  the  highest  score  (36/40),  and  exceeded  the 
score  assigned  to  the  MMA  (22/40),  running  counter 
to  the  a  priori  maturity  hypothesis. 

Comparing  across  the  candidate  system,  the  lowest 
scores  were  assigned  to  the  Team  Processes  (40/120 
and  the  highest  to  team  Goals  (53/120).  Comparing 
the  individual  constructs,  total  scores  ranged  from 
5/16  (Goal  Tracking)  to  15/16  (Heterogeneity). 
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FIGURE  5  -  Audit  Component  Proportions 
8.6  Audit  Discussion 

The  audit  data  provide  the  briefest,  outline  sketch  of 
the  pattern  of  teamwork  across  crew-system  roles 
and  technologies.  The  absence  of  statistical 
procedures  makes  it  impossible  to  draw  firm 
conclusions.  However,  in  general  the  data  seem  to 
support  the  notion  that  the  teamwork  model  is  at 
least  sensitive  to  the  substantial  developments  in 
crew  systems  technologies  that  have  occurred  since 
the  early  1970s.  They  lend  support  to  the 
observation  that  advanced  computer  technology  has 


enabled  widespread  embodiment  of  mission  goal 
requirements  in  crew-system  design  and  enhanced 
mission  control  and  management.  On  the  other 
hand,  the  data  show  little  evidence  of  substantial 
improvements  in  teamwork  processes,  supporting  the 
common  observation  that  MMI  developments  tend 
to  lag  behind  progress  in  mission-system  capability. 
Notwithstanding,  advanced  teamwork  concepts,  such 
as  dynamic  function  allocation  (DFA)  and  levels  of 
autonomy  (LOA),  probably  are  significant, 
substantive  developments  in  teamwork  structure. 

Comparisons  between  assessments  across  roles  are 
confounded  by  the  choice  of  system  and  auditor  for 
comparison.  Both  the  MMA  and  AMPA  are  future 
systems  under  development.  Consequently,  their 
assessments  are  necessarily  speculative,  and 
therefore  less  reliable  than  those  concerned  with 
operational  systems.  It  should  be  noted  that  the 
comparatively  optimistic  AMPA  assessment  was 
provided  by  a  member  of  the  project  management 
team,  whereas  the  more  pessimistic  MMA 
assessment  was  provided  by  an  informed,  but 
healthily  sceptical  Tornado  pilot.  The  Tornado 
pilot’s  brief  was  to  compare  his  understanding  of  the 
prototypical  MMA  with  the  current  operationally 
successful  mission  system,  coupled  with  the 
Navigator.  Hence,  an  unusually  high  evaluation  is 
given  of  the  GR  1  team  processes,  which  are  strongly 
based  on  successful  human-human  communication. 
An  audit  by  the  MMA  design  team  probably  would 
have  been  more  optimistic  since  many  of  the  model 
features  are  compatible  with  MMA  design  goals. 
Although  these  limitations  on  the  audit  technique 
undoubtedly  exist,  and  limit  the  conclusions  that  can 
be  drawn  from  the  data,  this  approach  to  systems 
assessment  probably  has  potential  for  further 
development  as  a  high  level  diagnostic  tool,  if 
supported  by  more  scientific,  systematic  data 
gathering  procedures. 

9.  CONCLUSIONS 

The  proposition  that  teamworK  should  be  a  high- 
level  design  driver  poses  a  radical  departure  from 
conventional  systems  engineering  objectives.  This 
review  demonstrates  that  there  is  a  substantial 
understanding,  in  social  psychology,  of  the  processes 
of  teamwork,  sufficient  to  generate  a  potentially 
extensive  list  of  criteria  for  judging  the  quality  and 
maturity  of  Human-Electronic  Crew  teamwork.  The 
limitations  of  the  model  are  that  Human-Electronic 
Crew  teamwork  may  have  unique  emergent 
characteristics  that  are  not  evident  from  analysis  of 
human  teamwork.  A  major  problem  with  the  model 
is  that  it  is  based  on  a  high  degree  of  trust.  When 
distrust  occurs,  teamwork  breaks  down  in  a 
potentially  catastrophic  and  irredeemable  manner. 
This  may  result,  in  the  worst  case,  m  the  human 
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operator  refusing  to  use  any  of  the  electronic 
crewmember’s  capabilities.  The  distribution  of 
power  raises  the  issue  of  leadership,  with  consequent 
moral  and  political  implications  if  the  locus  of  power 
is  not  to  reside  with  the  human.  Such  a  prototype 
model  audit  is  unlikely  to  provide  a  fully 
comprehensive  analysis  of  the  issues.  However,  the 
aim  of  audit  is  to  judge  the  whole  through  a  sample 
of  relevant  criteria.  Although  more  statistically 
testable  validation  is  required,  this  model  may  have 
some  utility,  at  least,  in  conceptualising,  designing, 
and  validating  candidate  Human-Electronic  Crew 
teams.  The  provisional  results  reported  here 
indicate  that  the  model  is  sufficiently  relevant  and 
understandable  to  be  applied  by  system  users  with 
some  sensitivity  and  diagnostic  power.  It  remains  to 
be  seen  if  the  model  is  capable  of  generating 
interesting  predictions  and  hypotheses  that  can  be 
tested  both  empirically  and  operationally. 
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Abstract 

Rotorcraft  operating  in  high-threat  environment  fly  close 
to  the  earth’s  surface  to  utilize  surrounding  terrain,  veg¬ 
etation,  or  man-made  obj<  cts  to  minimize  the  risk  of 
being  detected  by  an  enemy.  The  piloting  of  the  rotor¬ 
craft  is  at  best  a  very  demanding  task  and  the  pilots  need 
help  from  on-board  automation  tools  in  order  to  devote 
more  time  to  mission-related  activities.  The  Automated 
Nap-of-the-Earth  (NOE)  Flight  Program  is  a  coopera¬ 
tive  NASA/Army  program  aimed  at  the  development 
of  technologies  for  enhancing  piloted  low-altitude/NOE 
flight  path  management  and  control  through  computer 
and  sensor  aiding.  The  long-term  objective  is  to  work 
towards  achieving  automation  for  aiding  the  pilot  in 
NOE  flight  with  a  flight  demonstration  of  resulting  com¬ 
puter/sensor  aiding  concepts  at  an  established  course. 
The  technology  for  pilot-centered  NOE  automation  is 
not  currently  available.  Success  in  automating  NOE 
functions  will  depend  on  major  breakthroughs  in  real¬ 
time  flight  path  planning  algorithms,  effective  methods 
for  the  pilot  to  interface  to  the  automatic  modes,  under¬ 
standing  of  visual  images,  sensor  data  processing/fusion, 
and  sensor  development.  Our  approach  to  developing  the 
technologies  required  to  solve  this  problem  consists  of  the 
following  phases:  (a)  algorithm  development,  (b)  labo¬ 
ratory  evaluation,  (c)  piloted  ground  simulation,  and  (d) 
evaluation  in  flight.  This  paper  gives  an  overview  of  the 
research  in  this  area  at  NASA  Ames  Research  Center. 

1  Introduction 

The  complexity  of  rotorcraft  missions  involving  oper¬ 
ations  close  to  the  ground  in  nap-of-the-earth  (NOE) 
flight  for  long  periods  of  time  result  in  high  pilot  work¬ 
load.  This  is  especially  true  for  single-pilot  vehicles,  such 
as  was  originally  intended  for  RAH-66  Comanche.  In 
order  to  allow  a  pilot  time  to  perform  mission-oriented 
tasks,  some  type  of  automatic  system  capable  of  per¬ 
forming  guidance  and  control  functions  would  be  highly 
desirable.  The  problem  of  automating  NOE  flight,  how¬ 
ever,  is  extremely  challenging  due  to  the  advances  nec¬ 
essary  in  several  technologies.  This  paper  describes  the 
status  of  research  at  NASA  in  three  key  areas:  (a)Terrain 
Following/Terrain  Avoidance,  (b)  obstacle  detection, 
and  (c)  obstacle  avoidance. 

Guidance  for  NOE  flight,  as  shown  in  Fig.l,  can  be 
divided  into  fat-field,  mid-field,  and  near-field  require¬ 
ments  that  can  be  envisioned  as  three  dependent  feed¬ 
back  loops  [l].  The  outer  loop  is  responsible  for  far- 
field  mission  planning  and  waypoint  selection,  tasks  that 


are  generally  performed  prior  to  flight,  but  can  benefit 
greatly  from  a  real-time  on-board  re-planning  capabil¬ 
ity.  The  middle  loop  governs  terrain  following  and  ter¬ 
rain  avoidance  about  the  nominal  waypoint  path.  The 
outer  and  middle  loop  guidance,  referred  to  as  database- 
derived  guidance,  uses  a  priori  information  about  terrain 
and  threat  leading  to  a  trajectory  planning  algorithm. 
The  database  is  unlikely  to  have  information  about  ob¬ 
jects  such  as  trees,  buildings,  wires,  etc.,  which  may  be 
in  the  flight  path  of  the  rotorcraft.  This  trajectory  is 
modified  by  the  inner-loop  obstacle  avoidance  guidance 
based  on  information  acquired  by  the  on-board  sensors 
and  is  a  critical  component  of  an  automatic  NOE  sys¬ 
tem.  Various  on-going  studies  are  addressing  the  issue  of 
on-board  sensors  that  could  facilitate  a  pilot  in  detect¬ 
ing  obstacles  in  the  flight  path.  The  obstacle  detection 
problem  is  posed  as  the  problem  of  finding  ranges  to  all 
objects  in  the  field  of  view  based  on  measurements  of 
the  optica]  flow  or  stereo  imagery.  A  complete  obstacle 
detection  system  would  require  the  integration  of  both 
active  and  passive  sensors  [2],  The  Army  has  several 
programs  to  develop  an  active  sensor,  and  we  are  em¬ 
phasizing  the  use  of  passive  electro-optical  sensors.  Such 
sensor  systems  could  allow  a  pilot  to  concentrate  less 
heavily  on  guiding  the  vehicle,  thus  allowing  more  time 
for  attending  weapons  and  communication  systems. 

The  maturity  of  different  technologies  required 
to  achieve  the  guidance  tasks  described  above  varies 
significantly.  The  Terrain  Following/Terrain  Avoid¬ 
ance  (TF/TA)  algorithms  and  display  concepts  used  in 
database-derived  guidance  have  reached  a  level  where 
they  can  be  tested  in  flight  under  operational  conditions. 
The  inner-loop  obstacle  avoidance  algorithms  have  been 
developed  in  a  graphics  workstation  environment  and  are 
ready  for  evaluation  in  piloted  simulations.  The  vision- 
based  obstacle  detection  technology  is  the  least  mature 
but  we  have  succesfully  applied  passive  ranging  algo¬ 
rithms,  for  the  first  time,  to  images  collected  in  a  CH-47 
helicopter  flight. 

The  paper  is  organized  as  follows:  Section  2  de¬ 
scribes  the  guidance  and  display  associated  with  the  op¬ 
erationally  ready  TF/TA  algorithms.  Section  3  describes 
the  inner  loop  obstacle  avoidance  guidance  algorithm. 
Section  4  provides  an  overview  of  a  maximally  passive 
ranging  system  using  elecrto-optical  sensors.  Finally, 
Section  5  provides  summary,  conclusions  and  ideas  for 
future  work. 


92-16176 


10-2 


Figure  1:  NOE  Guidance  Structure 

2  TF /TA  Guidance  2.1  System  Dejcription 

Fig.  2  shows  a  functional  block  diagram  of  the  CALAHF 
flight  system.  The  three  major  components:  (1)  Dynap- 
ath  trajectory-generation  algorithm,  (2)  trajectory  cou¬ 
pler,  and  (3)  displayed  information  are  discussed  below. 

Currently,  rotorcraft  operating  in  threat  areas  achieve 

low-level,  maneuvering  penetration  capability  during  Trajectory  Generation  Algorithm 
night-time  and  adverse  weather  conditions  through  the 

use  of  a  combination  of  technologies  such  as  terrain-  Dynapath  is  a  valley-seeking  trajectory  generating 

following  (TF)  radar  systems,  forward  looking  infrared  algorithm  based  on  a  forward-chaining  dynamic- 

and  night  vision  goggles.  TF  systems  were  initially  devel-  programming  technique  originally  developed  for  the  U  S. 

oped  for  fixed-wing  tactical  and  strategic  aircraft  [3]  and  Air  Force-  Significant  modifications  have  been  made  to 

provide  vertical  commands  which  can  be  displayed  on  a  tb*s  8u*dance  algorithm  to  adapt  it  for  manual  rotorcraft 

flight  director  for  manual  flight  or  fed  to  the  flight  control  operations.  The  algorithm  uses  two  types  of  inputs.  The 

system  for  automatic  flight.  The  extension  of  TF  capa-  first'  characterized  as  mission  dependent  information,  in- 

bility  to  include  lateral  maneuvering  by  taking  advantage  eludes  mission  waypoints  for  defining  a  global  trajectory 

of  on-board  digital  terrain  data  is  commonly  referred  to  to  be  flown'  and  Defense  MaPPin8  ASenc-V  diSitaJ  ter' 

as  Terrain  Following/Terrain  Avoidance  (TF/TA)  in  the  raln  elevatlon  data  of  tbe  area  ln  whlcb  the  mission  is  to 

literature.  Within  the  last  few  years  TF/TA  algorithms  be  accomplished.  The  second  kind  of  input  consists  of 

have  been  modified  to  suit  the  requirements  of  rotorcraft  pilot-comfort  and  aircraft-dependent  parameters,  max- 

[4].  Research  at  NASA  has  concentrated  on  incorpo-  imum  bank  an8le  commands,  maximum  climb  and  dive 

rating  these  algorithms  into  an  operationally  acceptable  an8le8’  maximum  pull  up  and  push  over  load  factor,  set- 

system,  referred  to  as  the  Computer  Aiding  for  Low-  clearance  altitude  (desired  trajectory  altitude  above  the 

Altitude  Helicopter  Flight  (CALAHF)  guidance  system.  ground)  along  with  sensed  aircraft  state  information. 
Several  piloted  simulations  [5]  of  the  CALAHF  guidance  Dynapath  uses  a  decoupled  procedure  in  which  the 

system  have  been  conducted  to  develop  the  system  and  lateral  and  vertical  trajectory  solutions  are  determined 

pilot  interface  and  to  evaluate  pilot  tracking  performance  independently  to  obtain  an  optimal  trajectory.  In  this 

and  situational  awareness  under  various  flight  and  en-  decoupled  procedure,  the  lateral  ground  track  is  first  de- 

vironmental  conditions.  The  very  favorable  pilot  feed-  termined  by  assuming  that  the  aircraft  can  maintain  the 

back  and  response  to  these  simulations  [6]  has  led  to  a  vertical  set-clearance  altitude.  The  vertical  trajectory 

joint  NASA  and  U.S.  Army  flight  test  of  the  CALAHF  is  then  calculated  using  aircraft  normal  load  factor  and 

flight  guidance  system.  The  NASA-developed  system  flight  path  angle  as  maneuver  constraints  to  maintain  the 

will  be  flown  on  the  U.S.  Army  Avionics  Research  and  aircraft  at  or  slightly  above  the  vertical  set  clearance  as 

Development  Activity’s  UH-60  STAR  (System  Testbed  determined  from  the  digital  terrain  map  and  the  lateral 

for  Avionics  Research)  research  helicopter.  ground  track. 
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Figure  2:  CALAHF  system  block  diagram 


The  lateral  path  is  calculated  using  a  tree  struc¬ 
ture  of  possible  two-dimensional  trajectories  by  using 
discrete  values  of  aircraft  bank  angle.  Assuming  con¬ 
stant  speed  and  coordinated  flight  (zero  sideslip),  each 
discrete  bank  angle  produces  a  possible  path  which  in 
combination  forms  a  tree  of  possible  paths  (Fig.  3).  In 
this  implementation,  the  bank  angle  control  has  five  dis¬ 
crete  values  that  are  used  for  the  trajectory  calculation. 
The  number  of  possible  paths  is  reduced  to  a  reasonable 
lnvel  by  pruning.  Pruning  the  tree  after  three  to  four  lev¬ 
els  of  branching  gave  the  best  mix  of  branch  generation 
and  computational  speed  based  upon  results  from  non- 
real-time  computer  simulations.  After  the  tree  structure 
of  possible  paths  has  been  propagated  through  the  en¬ 
tire  patch  length,  the  cumulative  cost  ( J)  of  all  surviving 
branches  are  compared,  and  the  path  with  the  lowest  cost 
is  selected  as  the  optimal  trajectory. 

The  cost  function  J  used  to  determine  the  optimal 
trajectory  is 

30 

J  =  YsH'+S(D)  (!) 

1=1 

where  H,  is  the  altitude  above  sea  level  at  node  i,  D , 
is  the  lateral  distance  from  reference  path  at  node  i,  u 
is  the  TF/TA  ratio,  /(D)  is  a  dead  band  on  the  lateral 
deviation  cost,  A't,  is  the  error  between  reference  and 
command  heading  at  node  i  and  a  is  the  heading  weight. 

The  main  parameters  in  this  performance  measure 
are  the  terms  representing  altitude  H  and  reference-path 
deviation  D.  The  cost-functional,  when  driven  by  these 
two  terms,  allows  lateral  maneuvering  to  seek  lower  alti¬ 
tude  terrain  by  the  cost  reduction  from  H ;  excessive  de¬ 
viation  from  the  reference  path  is  controlled  by  increas¬ 
ing  cost  due  to  D.  The  TF /TA  ratio  w  allows  blending  of 
these  two  terms  to  obtain  a  desired  balance  between  ver¬ 
tical  and  horizontal  maneuvering.  The  f(D) and  or(A4',) 
terms  were  added  to  reduce  undesirable  oscillations  in 
the  trajectory  about  the  nominal  path  that  are  caused 
by  the  bank-angie  quantization.  The  f(D)  eliminates 
the  need  for  precise  following  of  the  reference  path  and 
the  o(A'i,)  term  provides  a  penalty  for  changing  the 
heading  from  that  given  by  the  reference  path.  These 
two  terms  were  added  as  a  result  of  experience  gained  in 
piloted  simulations  to  make  the  trajectory-generation  al¬ 
gorithm  emulate  pilot  control  strategies  for  low-altitude 


maneuvering  flight. 

The  trajectory-generation  algorithm,  as  defined 
above,  is  designed  to  compute  guidance  for  a  patch  which 
is  the  area  in  front  of  the  aircraft’s  present  location.  The 
patch  width  is  the  maximum  lateral  deviation,  and  the 
length  is  the  flight  preview  distance.  Both  are  input  pa- 
rameters  selected  by  the  user.  The  algorithm  is  computa¬ 
tionally  intensive:  using  representative  values  for  patch 
length  (30  sec)  and  maximum  lateral  deviation  (1  km) 
the  computational  cycle  is  approximately  4  to  5  sec  for 
a  modern  (1  to  2  MIP)  flight  computer.  Although  the 
algorithm  is  updated  every  cycle  ti  ,ie,  the  updates  are 
blended  in  such  a  way  that  a  pilot  sees  a  continuous  path 
and  the  updates  are  imperceptible  to  him. 

Trajectory  Coupler 

After  the  Dynapath  algorithm  produces  its  optimal  tra¬ 
jectory  it  is  passed  to  the  trajectory  coupler.  The  tra¬ 
jectory  is  represented  by  30  discrete  instances  of  com¬ 
manded  aircraft-inertial  state  (position,  velocity  and  ac¬ 
celeration)  at  1  sec  intervals.  Also  stored  are  com¬ 
manded  bank  angles,  headings  and  vertical  flight-path 
angles.  The  trajectory  coupler,  converts  the  quantized 
commanded  trajectory  into  a  trajectory  command  that  is 
designed  to  work  synchronously  with  the  pilot  displays 
at  a  minimum  of  20  Hz,  thus  not  imposing  any  time- 
delay  that  is  perceptible  to  the  pilot.  This  is  accom¬ 
plished  by  interpolating  within  the  trajectory  to  deter¬ 
mine  the  instantaneous  position  of  the  trajectory  points 
to  be  presented  on  the  pilots  head-up-display.  In  the  fu¬ 
ture,  when  the  TF/TA  guidance  is  integrated  with  the 
obstacle  avoidance  guidance  (OAG)  according  to  Fig.  1, 
the  OAG  will  replace  this  trajectory  coupler  function. 

Displayed  Information 

The  guidance  and  control  information  is  displayed  to  the 
pitot  on  a  helmet  mounted  display  (HMD)  in  the  format 
shown  in  Fig.  4.  The  HMD  format  is  a  mixture  of  screen, 
body,  and  inertially  referenced  symbols.  The  screen  ref¬ 
erenced  symbols  include:  a  heading  tape  (021),  engine 
torque  (  45%),  airspeed  (63  kts),  radar  altitude  (  105  ft), 
and  ball  and  slip  indicator.  The  body  referenced  sym¬ 
bols  are  the  aircraft  nose  (  ><  ),  and  the  flight-path  vec¬ 
tor/predictor.  All  remaining  symbols  are  inertially  refer- 
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Figure  3:  Dvnapath  tree  generation 


enced.  The  primary  situational  information  is  presented 
to  the  pilot  with  an  inertially  stabilized  flight-path  vec¬ 
tor/predictor  symbol  predicting  the  rotorcraft  location  4 
seconds  ahead,  represented  by  the  circular  aircraft  icon 
with  attached  airspeed  flight  director  tape.  The  situa¬ 
tional  information  presented  on  the  HMD  in  Fig.  4  in¬ 
dicates  the  pilot  is  turning  right  with  a  slight  descent  as 
indica  :d  by  the  flight-path  vector/predictor  below  the 
horizon,  and  is  looking  approximately  along  the  longitu¬ 
dinal  axis  of  the  aircraft  as  indicated  by  the  position  of 
the  aircraft  nose  symbol. 

The  Dynapath  trajectory  information  on  the  HMD 
is  given  by  the  pathway-in-the-sky  and  phantom  aircraft. 
The  pathway  symbols  represent  a  three-dimensional  per¬ 
spective  of  the  inertial  position  and  heading  of  the  dis¬ 
cretized  Dynapath  trajectory.  The  phantom  aircraft  is 
displayed  on  the  HMD  as  a  delta- wing  aircraft.  The 
phantom  aircraft  represents  the  instantaneous  position 
along  the  Dynapath  trajectory  that  is  4  seconds  ahead 
of  the  pilot’s  aircraft.  By  positioning  the  flight-path  vec¬ 
tor  symbol  on  the  phantom  aircraft,  the  pilot  will  track 
the  desired  trajectory.  In  Fig.  4,  the  HMD  symbols  are 
presenting  a  climbing  right  turn. 

The  pathway  is  100  ft  (roughly  two  rotor  diameters) 
wide  at  the  bottom  and  parallel  to  the  horizon  with  ver¬ 
tical  projections  that  are  canted  at  a  45  angle;  the  width 
at  the  top  is  200  ft.  The  depth  of  the  path  is  50  ft 
below  the  intended  trajectory;  thus  when  flying  a  level 
straight-line  commanded  path,  the  pilots  used  the  anal¬ 
ogy  of  traveling  in  a  full  irrigation  canal  for  describing 
the  pathway  symbols.  Fig.  4  shows  the  baseline  config¬ 
uration  of  7  lines. 

2.2  Piloted  Simulation 

There  have  been  five  piloted  simulations  dedicated  to 
the  development  and  evaluation  of  the  computer  aid¬ 
ing  for  low-altitude  helicopter  flight  guidance  concepts 
[5,  6j.  The  simulations  have  been  conducted  on  the  Ames 
Research  Center  six-degree-of-freedom  Vertical  Motion 
Simulator  (VMS).  The  VMS  provides  extensive  cockpit 


motion  for  use  in  evaluating  handling  qualities  associ¬ 
ated  with  advanced  guidance  concepts  for  existing  and 
proposed  aircraft.  Based  on  the  system  performance  and 
pilot  acceptance  demonstrated  during  the  third  simula¬ 
tion,  the  concept  was  believed  to  be  ready  for  flight  eval¬ 
uation,  both  as  a  first  step  in  initiating  Automated  NOE 
flight  research  and  a  standalone  capability  to  meet  the 
operational  military  requirements  for  covert  low-altitude 
penetration.  This  resulted  in  an  agreement  between 
NASA-Ames  and  the  U.S.  Army  Avionics  Res*  arch  and 
Development  Activity  (AVRADA)  for  a  joint  flight  ex¬ 
periment  in  the  AVRADA  UH-60  STAR  helicopter.  The 
final  two  simulations  were  conducted  in  direct  support  of 
the  flight  test  program.  In  the  fifth  simulation,  5  NASA 
and  Army  project  pilots  flew  over  300  simulation  data 
runs  evaluating  and  defining  the  system  throughout  the 
proposed  flight  test  envelope.  Eighteen  guest  and  eval¬ 
uation  pilots  from  NASA,  DOD  and  U.S.  industry  flew 
the  system,  giving  highly  favorable  feedback  on  the  sys¬ 
tem  development.  The  evaluation  pilots  were  able  to 
manually  track  the  HMD  guidance  through  various  com¬ 
binations  of  terrain,  speeds,  and  weather  representative 
of  system  use.  The  guidance  can  be  followed  with  low 
pilot  workload  without  detracting  from  his  awareness  of 
the  outside  world.  The  pilot  was  able  to  combine  the 
guidance  with  his  visual  senses  to  optimize  the  mission 
success  in  varying  weather/threat  conditions. 

3  Obstacle  Avoidance  Guidance 

The  obstacle  avoidance  guidance  (OAG)  assumes  that 
the  database-driven  guidance  would  provide  the  nomi¬ 
nal  course  to  be  followed.  The  OAG  is  motivated  by 
the  recognition  that  it  is  unreasonable  to  expect  the 
database  to  be  precise  and  up-to-date  enough  to  con¬ 
tain  detailed  obstacle  information.  Neither  would  it  ex¬ 
pect  the  obstacle-detection  system  to  be  powerful  enough 
to  provide  the  locations  and  sizes  of  all  the  obstacles. 
Specifically,  the  sensors  would  not  be  able  to  detect  ob¬ 
stacles  hidden  behind  other  objects,  and  the  obstacle- 
avoidance  guidance  system  has  to  operate  within  such 
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Figure  4:  Helmet  Mounted  display  format 


a  limitation.  We  assume  that  the  sensors  can  provide  a 
sparse  range  map  within  the  sensors’  field  of  regard.  Our 
approach  involves  selective  augmentation  of  the  sparse 
range  data  with  measurements  from  active  ranging  sen¬ 
sors  to  assure  safe  flight  [2].  The  guidance  does  not  use 
pre-designed  discrete  obstacle  avoidance  maneuvers  but 
instead  makes  continuous  adaptations  to  the  flight  path 
based  upon  updated  sensor  range  information.  Further, 
the  guidance  does  not  assume  a-priori  knowledge  of  the 
distinction  between  obstacles  and  terrain,  but  instead 
accomplishes  this  differentiation  using  real-time  compu¬ 
tation  as  would  be  necessary  in  actual  flight. 

3.1  Input  Data  Preprocessing 

Course-following  guidance  is  accomplished  by  tracking 
an  imaginary  reference  point  that  is  placed  ahead  of  the 
vehicle  on  the  nominal  path  by  a  distance  proportional 
to  the  rotorcraft’s  velocity.  Fig.  5  contains  a  block  dia¬ 
gram  of  the  OAG  structure.  During  each  guidance  cycle, 
the  obstacle  detection  system  provides  three-dimensional 
range  information  in  body-fixed  coordinates.  This  3-D 
range  map  simply  provides  the  numerical  distance  from 
the  rotorcraft  to  terrain  or  obstacles,  currently  modeled 
in  the  simulation  to  be  available  within  a  60”  field  of 
view  in  both  azimuth  and  elevation.  To  emulate  pas¬ 
sive  sensor  characteristics,  range  information  is  stored  by 
perspective  projection  in  a  128  x  128  pixel  array  repre¬ 
senting  the  focal  plane  of  a  FLIR  or  TV  image.  From  the 
body-fixed  reference  frame,  the  3-D  range  information  is 
transformed  to  inertial  coordinates  and  stored.  At  any 
time,  the  derived  inertial  database  includes  terrain  and 
obstacle  data  within  350m  longitudinally  and  laterally 
to  the  vehicle  position.  Based  on  the  inertial  database, 
a  simple  test  is  performed  to  differentiate  obstacles  from 
terrain.  This  test  involves  examining  the  3-D  data  base, 
which  is  altitude  as  a  function  of  horizontal  displace¬ 
ment.  for  large  changes  in  altitude.  Upon  differentiating 
the  terrain  and  obstacle  data,  the  obstacle  data  is  used 
to  construct  a  2-D  range  map  while  the  terrain  data  is 
stored  to  provide  terrain  following  guidance. 

3.2  Flight  Path  Selection 

Path  selection  begins  by  determining  whether  any  ob¬ 
structions  lie  in  a  direct  path  to  the  reference  point. 


where  the  path  is  at  least  as  wide  as  the  rotor  diame¬ 
ter  with  additional  predefined  clearance.  If  a  clear  path 
is  available,  a  velocity  command  is  given  in  the  direc¬ 
tion  of  the  reference  point.  If  obstructions  exist,  the  2-D 
inertial  range  map  is  inspected  for  an  alternate  route. 
A  potential  path  from  the  range  map  is  indicated  by  a 
discontinuity  in  range  vs.  azimuth  angle  [7],  A  further 
requirement  for  a  potential  route  is  that  the  difference  in 
range  on  either  side  of  the  discontinuity  must  be  greater 
than  the  rotor  diameter  in  order  to  allow  for  turning  into 
the  opening  (see  Fig.  6).  If  more  than  one  possible  open¬ 
ing  is  found,  the  selection  is  based  on  the  path  that  min¬ 
imizes  the  deviation  from  the  nominal  course.  Once  an 
opening  is  found,  a  velocity  command  is  given  along  the 
open  direction.  In  some  instances  there  may  be  no  open 
path  available,  in  which  case  the  vehicle  is  commanded  to 
initiate  a  pedal  turn  towards  the  reference  point.  Upon 
facing  the  reference  point,  a  velocity  command  to  the  ref¬ 
erence  point  is  given  along  with  climb  commands  that  al¬ 
low  the  rotorcraft  to  climb  with  constant  heading  to  clear 
the  terrain  and  obstacles,  i.e.  the  vehicle  switches  to  con¬ 
tour  flight.  The  terrain  data  from  the  inertial  database 
along  the  commanded  2-D  path  provides  the  necessary 
information  to  generate  commands  in  the  vertical  plane. 

These  algorithms  nave  recently  been  implemented 
in  a  workstation-based  simulation  for  evaluation.  Fig.  7 
contains  an  example  of  an  automatically  guided  flight 
path  about  the  nominal  trajectory  in  white.  Details 
of  the  guidance  and  control  implementation  will  be  re¬ 
ported  in  a  future  paper. 


4  Vision  Based  Obstacle  Detection 

The  vision  system  is  intended  to  provide  the  on-board 
information  necessary  to  modify  the  nominal  trajectory 
of  the  rotorcraft  provided  by  far-field  and  mid-field  plan¬ 
ning.  NASA  research  focuses  on  identifying  and  devel¬ 
oping  the  key  components  of  a  vision  based  obstacle  de¬ 
tection  capability  for  rotorcraft  NOE  flight.  The  compo¬ 
nents  of  an  obstacle  detection  system  is  shown  in  Fig.  8. 
We  assume  that  one  or  more  passive  electro-optical  sen¬ 
sors  is  installed  on  the  rotorcraft.  In  addition,  we  assume 
that  an  inertial  navigation  system  and  other  sensors  will 
be  available  to  provide  the  rotorcraft  velocity  and  body 
rates.  Because  vision  alone  will  not  be  adequate  for  de- 
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Kigurt  7:  Kx ample  of  automatically  guided  flight  path 


tecting  small  obstacles  such  as  wires,  it  is  expected  that 
the  system  will  include  an  active  ranging  sensor  whose 
search  area  can  be  directed  to  complement  the  vision  sys¬ 
tem  to  minimize  detectability  [jj.  Rotorcraft  maneuvers, 
natural  scenery,  and  the  availability  of  accurate  vehicle 
position  and  attitude  measurements  motivate  a  new  look 
at  vision  algorithms  developed  for  robotics  ami  machine 
inspection 

The  obstacle  detection  system  requires  finding 
ranges  to  all  objects  in  the  field  of  view  using  a  sequence 
of  images.  This  problem  can  he  broken  into  two  steps. 
The  first  step  consists  of  the  computation  of  optical  flow 
I  he  second  step  involves  the  use  of  the  optical  flow  to  es¬ 
timate  range.  Ihe  computation  of  optical  flow  requires 
the  determination  of  the  displacement  of  image  points 
over  a  sequence  of  images.  The  main  difficulty  in  the 
computation  is  due  to  the  assumption  that  an  object  in 
the  terrain  space  corresponds  to  a  unique  point  in  the  im¬ 
age.  In  an  actual  image,  an  object  on  the  ground  is  more 
likely  to  be  a  region  in  the  image  Another  complication 


in  the  computation  of  the  optical  flow,  referred  to  as  the 
correspondence  problem,  results  from  the  ambiguity  in 
identifying  features  in  two  images  that  are  projections  of 
the  same  entity  in  the  3-dimensional  world. 

The  computation  of  optical  flow  using  two  succes¬ 
sive  images  has  been  an  active  area  of  research  in  com¬ 
puter  vision.  I  he  methods  used  can  be  divided  into  two 
categories: 

I.  Ihe  feature- based  approach  tom  putt's  ranges  to  ex¬ 
plicitly  identified  features  in  the  images,  which  can 
be  points,  lines,  contours  or  any  other  clearly  dis¬ 
tinguishable  part  of  the  image.  Ihe  extraction  of 
features  [*]  in  an  image  involves  several  operations 
such  as  enhancement,  edge  detection,  linking  and 
scene  analysis.  A  fundamental  assumption  of  this 
approac  h  is  that  correspondence  between  features 
in  two  images  needs  to  be  established  prior  to  corn 
putation  of  range. 

The  field -based  techniques  assume  a  continuous 
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Figure  8:  Components  of  an  Obstacle  Detection  System 


variation  of  image  intensity  as  a  function  of  posi¬ 
tion  and  time.  This  approach  was  introduced  by 
Horn  [9]  and  provides  a  dense  map  of  the  optical 
flow.  However,  the  computational  experience  with 
this  approach  is  limited  to  simple  scenes  and  the  ac¬ 
curacy  of  available  algorithms  based  on  this  method 
is  very  susceptible  to  noise. 

Our  feature-based  algorithms  are  based  on  feature 
tracking  followed  by  recursive  range  estimation  using  an 
extended  Kalman  filter  [10,  11,  12).  They  differ  from 
earlier  approaches  in  several  different  ways.  The  ex¬ 
traction  of  range  information  and  the  simultaneous  es¬ 
timation  of  the  observer  (rotorcraft)  motion  parameters 
(translational  and  rotational  velocity),  using  only  image 
data,  leads  to  ill-conditioned  computations.  In  the  case 
of  the  rotorcraft,  the  motion  parameters  can  be  mea¬ 
sured  independently  using  an  on-board  navigation  sys¬ 
tem;  consequently  the  use  of  image  data  only  to  extract 
range  information  results  in  more  stable  computations. 
The  knowledge  about  the  rotorcraft  motion  is  used  to 
reduce  the  amount  of  computation  in  establishing  the 
correspondence  between  features  as  well  as  to  discard 
false  matches.  All  the  algorithms  are  structured  such 
that  they  can  handle  a  sequence  of  images  in  a  recur¬ 
sive  manner  and,  unlike  several  algorithms  reported  in 
the  literature,  are  not  limited  to  linear  motion  of  the 
rotorcraft. 

We  are  developing  a  field-based  algorithm  based  on 
the  direct  computation  of  range.  The  equation  for  range 
is  derived  by  combining  local  Taylor  series  expansion  for 
image  irradiance  in  a  pair  of  images  with  the  geometry  of 
perspective  projection.  This  ranging  equation  relates  the 
image  irradiance  gradients  and  the  camera  and  motion 
parameters  to  range.  This  process  also  yields  a  second 
equation  that  predicts  the  error  involved  in  the  approx¬ 
imation.  An  optimal  method  for  satisfying  the  ranging 
equation  is  then  developed  for  computing  range  [13].  In 
addition,  we  are  considering  (a)  the  application  of  3- 
dimensional  Fourier  transform  to  a  sequence  of  images 


resulting  in  a  shift  and  add  algorithm  [14]  and  (b)  an  in¬ 
tensity  gradient  approach  [15].  The  field-based  methods 
are  developed  for  linear  helicopter  motion  and  are  being 
modified  to  handle  general  helicopter  motion. 

We  are  also  exploring  the  use  of  two  or  more  imag¬ 
ing  sensors  (stereo)  to  provide  better  range  information 
near  the  focus  of  expansion  [18].  The  Kalman  filter  for¬ 
mulation  allows  the  use  of  several  electro-optical  sensors 
and  it  provides  for  a  natural  way  of  integrating  stereo 
and  motion  methods.  In  addition,  since  quantitative  vi¬ 
sion  based  algorithms  do  not  provide  range  to  all  points 
in  the  field  of  view  (FOV),  we  are  also  investigating  the 
use  of  qualitative  vision  algorithms  such  as  scene  analysis 
to  fill  the  gaps  in  the  range  map  [19], 

A  major  issue  in  the  implementation  of  vision  al¬ 
gorithms  is  the  trade  off  between  computational  speed 
and  the  denseness  of  the  range  map.  Due  to  the  chang¬ 
ing  nature  of  the  hardware  and  our  desire  for  develop¬ 
ing  portable  software,  until  recently,  we  have  addressed 
this  problem  only  at  the  algorithmic  level.  We  plan  to 
achieve  the  goal  of  real-time  implementation  by  using 
parallel  computation.  Currently,  the  feature-based  pas¬ 
sive  ranging  algorithm  is  being  restructured  to  exploit 
the  inherent  parallelism  in  the  algorithm  and  for  imple¬ 
mentation  in  a  iWARP  parallel  computer  system  [20]. 
These  issues  will  be  studied  in-depth  with  the  end  result 
of  developing  a  real-time  vision  system. 

4.1  Evaluation  of  Range  Algorithms 

We  plan  to  evaluate  all  our  algorithms  using  image  se¬ 
quences  acquired  in  the  laboratory  and  in  flight.  An 
experiment  has  been  designed  to  acquire  a  sequence  of 
images  in  the  laboratory  by  using  a  camera  mounted  on  a 
3  degree-of-freedom  motion  table.  The  camera  position 
and  orientation  is  controlled  by  a  computer  to  achieve 
desired  curvilinear  camera  motion.  The  camera  can  be 
moved  at  different  speeds.  This  experiment  can  be  scaled 
to  simulate  a  helicopter  flying  at  20  knots  where  the  ob- 
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jects  in  the  FOV  vary  from  50m  to  500m  and  the  images 
are  processed  for  range  computation  every  0.25  seconds. 
Fig.  9  shows  the  image  processing  laboratory  setup.  A 
detailed  description  of  the  hardware  and  software  used 
in  the  acquisition  of  laboratory  images,  evaluation  of  vi¬ 
sion  algorithms  for  range  estimation,  and  visualization 
of  the  results  can  be  found  in  [16],  Results  of  process¬ 
ing  the  laboratory  images  indicate  that  it  is  posssible  to 
estimate  range  to  an  accuracy  of  5  to  10%  [12]. 

NASA  Ames  has  recently  developed  a  database  from 
CH-47  helicopter  flight  data  including  imagery,  rotor- 
craft  attitude  and  position  time  histories,  camera  pa¬ 
rameters,  and  ground  truth  range  measurements  [17], 
The  flight  experiment  designed  to  collect  the  necessary 
data  is  depicted  in  Fig.  10.  The  video  camera  was 
rigidly  mounted  under  the  rotorcraft  nose  and  oriented 
roughly  along  the  direction  of  flight  so  as  to  observe  des¬ 
ignated  obstacles  of  interest  which  the  rotorcraft  would 
encounter.  True  range  measurements  were  obtained  us¬ 
ing  a  ground-based  laser  tracker.  We  have  checked  the 
flight  data  for  consistency  using  a  state  estimation  tech¬ 
nique.  The  calibration  of  the  camera  in  an  operational 
system  required  modification  of  camera  calibration  algo¬ 
rithms.  The  database  includes  typical  flight  profiles  such 
as  straight  and  level  flight,  banked  and  curved  flight, 
pedal  turns,  bob-ups,  and  transitions  to  and  from  hover. 
The  flight  database  will  be  available  to  vision  researchers 
to  evaluate  algorithms. 

Fig.  11  shows  the  first,  25th,  50th,  and  the  last 
image  in  a  sequence  of  75  images  from  the  database. 
These  images  were  collected  at  a  frame  rate  of  30/sec  (33 
milliseconds  between  successive  images).  The  helicopter 
is  flying  straight  above  the  runway  at  an  altitude  varying 
between  13  and  14  feet  and  speed  varying  between  18  to 
20  knots.  The  helicopter  covers  a  distance  of  about  a  foot 
between  images.  The  laser  tracker  was  used  to  measure 
the  distances  to  the  trucks  A,  B,  C,  and  D  parked  along 
the  runway.  This  information  is  used  to  generate  the 
truth  data  shown  in  Table  1  relative  to  the  helicopter 
location  at  the  75th  image.  The  true  range  varies  by 
±10  feet  depending  on  different  parts  of  the  truck. 

Features  in  the  images  were  tracked  and  their  posi¬ 
tions  provided  to  the  extended  Kalman  filter.  There  are 
several  features  associated  with  a  single  object  on  the 
ground.  We  computed  the  mean  and  standard  devia¬ 
tion  of  the  range  estimates  for  all  features  corresponding 
to  a  single  object.  These  results  are  shown  in  Table  1. 
The  range  estimates  agree  well  with  the  true  range  for 
trucks  A,  C,  and  D.  Note  that  a  portion  of  the  standard 
deviation  in  the  estimated  range  is  due  to  the  fact  that 
different  parts  of  a  truck  are  at  different  ranges  from 
the  camera.  The  range  estimate  to  the  truck  B  is  less 
accurate,  having  an  error  of  13.3%  and  a  standard  devi¬ 
ation  of  72  feet,  both  larger  than  the  quantities  for  the 
other  trucks.  The  reasons  for  the  poor  performance  of 
the  range  estimate  algorithm  for  truck  B  are:  (a)  truck 
B  is  farther  from  the  sensor  than  trucks  A,  C,  and  D; 
(b)  truck  B  is  only  about  5  degrees  away  from  the  FOE 
(which  is  shown  as  an  "X”  in  the  lower  right  image  at 
Fig.  12).  The  estimation  error  for  an  object  like  truck 
B  can  be  reduced  by  the  use  of  stereo. 

In  summary,  we  have  presented  for  the  first  lime  re- 


Table  1:  Passive  Range  Estimates  using  Flight  Images 


Truck 

True 

Range 

ft 

Est 

Range 

ft 

Std 

Dev 

ft 

%error 

A 

325 

324 

25 

0.3 

B 

576 

499 

72 

13.3 

C 

451 

452 

50 

0.2 

D 

205 

215 

10 
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suits  on  the  feasibility  of  using  vision-based  algorithms 
for  acquiring  range  information  using  images  acquired 
from  helicopter  flight.  Our  contributions  are  twofold: 
(a)  development  of  a  flight  and  image  database  for  ver¬ 
ification  of  vision  based  algorithms  and  (b)  a  passive 
ranging  methodology  tailored  to  the  needs  of  helicopter 
flight.  Our  preliminary  results  indicate  that  it  is  pos¬ 
sible  to  get  adequate  range  estimates  except  at  regions 
close  to  the  FOE.  As  we  get  closer  to  the  FOE,  the  error 
in  range  increases  since  the  magnitude  of  the  disparity 
gets  smaller  resulting  in  a  low  signal  to  noise  ratio.  We 
plan  to  continue  the  evaluation  of  the  method  using  sev¬ 
eral  different  flight  scenarios  namely  (a)  helicopter  ap¬ 
proaching  the  runway  while  performing  a  turn  and  bank 
maneuver,  (b)  helicopter  performing  a  bob- up,  (c)  other 
scenarios  for  which  we  have  truth  data,  and  (d)  scenar¬ 
ios  with  different  contrasts  between  the  objects  and  the 
background. 

The  performance  of  the  motion-based  passive  rang¬ 
ing  method  can  be  improved  near  the  FOE  by  using 
stereo  (two  or  more  cameras).  We  have  developed  an 
integrated  stereo  and  motion  algorithm  using  the  EKF. 
The  use  of  stereo  has  additional  benefits.  Stereo  pro¬ 
vides  range  information  when  the  helicopter  is  station¬ 
ary  and,  further,  the  stereo  range  can  be  used  to  ini¬ 
tialize  the  EKF.  Passive  ranging  algorithms,  in  general, 
provide  range  information  only  in  regions  of  the  image 
where  there  is  a  variation  in  image  intensity.  The  re¬ 
sulting  sparse  range  map  can  be  improved  using  other 
vision  based  methods  such  as  texture  analysis  and  seg¬ 
mentation  to  fill  gaps  in  the  range  map  based  on  optical 
flow. 

5  Concluding  Remarks 

Research  is  continuing  at  NASA  Ames  in  the  devel¬ 
opment  of  automation  tools  for  rotorcraft  low-altitude 
flight.  We  have  focused  our  attention  on  (1)  TF/TA 
guidance,  (2)  obstacle  avoidance,  and  (3)  vision-based 
obstacle  detection.  Our  intent  is  to  test  each  of  the 
above  technologies  in  both  laboratory  and  in  flight.  Of 
the  topics  discussed  above,  the  database-derived  guid¬ 
ance  is  most  mature  and  a  flight  lest  is  being  planned 
for  the  near  future  to  evaluate  the  pilots  ability  to  man¬ 
ually  track  the  TF/TA  guidance  and  its  impact  on  pilot 
workload  and  situational  awareness.  The  obstacle  avoid¬ 
ance  research  has  led  to  the  development  of  a  three- 
dimensional  obstacle  avoidance  guidance  methodology 
which  makes  realistic  assumptions  on  the  capabilities  of 
active  and  passive  sensors.  The  sensor-derived  obstacle 
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avoidance  guidance,  with  an  active  sensor  in  the  initial 
phase,  will  need  further  refinement  to  make  it  more  adap¬ 
tive  to  the  unpredictable  environment  and  acceptable 
to  pilots  before  a  flight  test  can  be  contemplated.  The 
vision-based  obstacle  detection  system  approach  has  re¬ 
sulted  in  a  range  estimation  technique  which  can  handle 
general  helicopter  manuevers  and  large  variations  in  the 
optical  flow  encountered  during  flight.  We  have  demon¬ 
strated  the  first  application  of  vision-based  methods  to 
helicopter  flight  data.  The  obstacle  detection  system 
based  on  eletro-optical  sensors  is  an  extremely  complex 
problem  and  requires  further  evaluation  using  additional 
flight  data  and  substantial  effort  towards  achieving  real¬ 
time  implementation.  We  are  also  considering  near-term 
applications  of  the  above  technologies  for  simplified  sit¬ 
uations. 
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Summary 

A  knowledge  based  computer  aid  foi  flight 
planning  tasks  as  part  of  a  Cockpit  Assistant 
for  IFR  (Instrument  Flight  Rules)  operation 
is  presented  in  detail  after  a  brief  overview  of 
the  modular  structure  of  the  Cockpit  Assistant 
has  been  given. 

Based  upon  the  requirements  of  air  traffic 
management  the  system  is  aimed  at  suppor¬ 
ting  the  pilot  in  complex  planning  and  decision 
situation.  By  assessing  the  situation  flight  goal 
conflicts  are  detected  and  avoided  by  offering 
sensible  flight  plan  modifications  to  the  pilot. 
The  main  features  of  the  situation  assessment 
and  planning  module  are  discussed  with  re¬ 
gard  to  knowledge  representation  and  applied 
solution  model.  Thus,  conflict  detection,  se¬ 
lection  of  an  alternate  destination  and  rerou¬ 
ting  algorithms  are  described  in  detail. 

The  present  state  of  implementation,  as  tested 
in  a  flight  simulation  facility  at  the  University 
of  the  German  Armed  Forces  in  Munich  is 
presented  as  well  as  some  results  of  the  test 
phase  with  professional  pilots. 

The  possibilities  of  integrating  the  system  into 
the  avionics  of  modern  aircraft  are  discussed 
and  an  outlook  is  given  of  expanding  it  towards 


4-D  and  RNAV  capability  and/or  optimal  3-D 
aircraft  trajectory  planning  under  constraints 
from  terrain,  traffic  and  weather. 

1.  Introduction 

Modern  civil  aviation  essentially  consists  of 
flights  under  Instrument  Flight  Rules  (IFR) 
to  keep  it  indepedent  of  meteorological  con¬ 
ditions.  Highly  developed  aircrafts  and  the 
complexity  of  Air  Traffic  Management 
(ATM)  require  the  pilot’s  attention  especially 
in  critical  situations.  System  failures,  weather 
changes  as  well  as  changing  constraints  from 
ATC  may  overstress  the  pilots,  in  the  wake  of 
which  wrong  decisions  and  accidents  possibly 
occur. 

Research  on  aircraft  accidents  [1]  and  the 
knowledge  of  human  information  processing, 
like  findings  of  Rasmussen  [2]  among  others, 
has  shown  that  one  major  aspect  of  cockpit 
assistance  should  be  ihe  support  in  situation 
assessment  and  replanning  in  flight.  The  well- 
structured  IFR  problem  space  offers  best  pre¬ 
mises  for  computer-aided  problem  detection. 
Knowledge  of  the  flight  plan  and  the  overall 
situation  enables  the  system  to  detect  conflicts 
and  modify  the  flight  plan  sensibly  using  the 
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principle  of  problem  reduction.  The  necessity 
of  basic  plan  modifications  can  be  carried  out 
in  the  same  manner,  whereas  decisions,  sub¬ 
ject  to  uncertain  and  fuzzy  criteria,  require 
additional  algorithms. 

For  complete  situation  assessment  and  eva¬ 
luation  monitoring  of  the  plan  execution  as 
well  as  of  the  aircraft  systems  and  environment 
is  required.  This  includes  the  ability  of  the 
system  to  communicate  with  the  pilot  and 
ATC.  Therefore  the  need  for  other  modules 
and  interfaces  is  given,  resulting  in  a  modular 
structured  Cockpit  Assistant,  which  comprises 
these  features.  This  Assistant  for  Single-Pilot 
IFR  Operation  (ASPIO)  has  been  implemen¬ 
ted  and  tested  in  a  flight  simulator  with  good 
acceptance  by  the  pilots  [3]  [4].  Figure  1  shows 
the  integration  of  the  Cockpit  Assistant  into 
the  air  traffic  system. 


Figure  1 :  Integration  of  the  Cockpit  Assistant  into 
the  air  traffic  system 

2.  Structure  of  the  Cockpit 
Assistant 

2.1.  Modular  structure  and  information  flow 

In  figure  2  the  major  modules  and  the  infor¬ 
mation  flow  of  the  Cockpit  Assistant  are  pre¬ 
sented.  Additional  modules  offering  special 
services  and  executional  aids  to  the  pilot  are 
left  out  of  this  representation,  although  they 
proved  to  be  quite  helpful  to  the  pilot.  The 


complete  modular  structure  of  ASPIO  can  be 
taken  from  figure  9. 


Figure  2 :  Structure  and  information  flow  of  the 
Cockpit  Assistant 

During  a  flight,  where  no  problems  occur  and 
no  replanning  is  necessary,  the  pilot  will  not 
become  aware  of  the  CA  modules  activi¬ 
ty.  The  need  for  a  flight  plan  modification  re¬ 
sults  from  the  situation  evaluation.  When  a 
new  plan  is  generated,  it  is  recommended  to 
the  pilot.  If  the  pilot  rejects  the  plan,  the  next 
best  alternative  will  be  presented.  This  proce¬ 
dure  continues  until  the  pilot  acknowledges  a 
plan.  The  new  flightplan  is  the  input  for  the 
following  module,  which  tries  to  model  the 
pilot’s  rule-based  behaviour:  The  expected  se¬ 
quences  of  actions  that  are  necessary  to  follow 
the  flightplan. 

These  expected  actions  establish  the  input  for 
the  monitoring  module.  This  module  compa¬ 
res  the  nominal  aircraft  state,  according  to 
flightplan  and  expected  pilot  actions,  to  the 
actual  aircraft  state.  When  a  discrepancy  is 
detected,  a  hint  is  given  to  the  pilot,  so  that 
small  errors  can  be  corrected  immediatly  and 
fatal  errors  can  be  avoided  before  they  occur. 
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22.  Interfaces  to  pilot  and  ATC 

The  pilot  interface  makes  use  of  the  most 
natural  communication  medium  between  hu¬ 
mans:  Speech.  Speech  output  is  used  especial¬ 
ly  for  recommendations,  warnings  and  advice. 
In  addition  to  speech  output  basic  flightplan 
modifications  are  presented  on  a  visual  dis¬ 
play.  Speech  input  is  used  for  acknow¬ 
ledgement  and  rejection  and  as  one  commun¬ 
ication  medium  for  instructions  to  the 
executional  aids  of  the  Cockpit  Assistant.  For 
speech  input  a  speaker-dependent  speech  re¬ 
cognition  system  is  used  based  on  the  phraseo¬ 
logy  of  civil  aviation. 

For  ATC  communication  a  digital  data  con¬ 
nection  has  been  assumed.  During  the  experi¬ 
mental  phase  ATC  commands  have  been  en¬ 
tered  into  the  computer  system  manually. 

3.  Situation  assessment  and  flight 
planning  module 


3.1.  Structure 


The  basic  knowledge  about  task  sequences 
during  an  IFR  flight  is  represented  as 
AND/OR  graph,  which  is  shown  in  figure  3  for 
the  approach  part  of  the  flight. 

The  prevailing  goal  is  to  perform  an  IFR  flight 
with  the  first  priority  to  fly  from  a  starting 
location  to  a  predetermined  destination.  If  this 
cannot  be  achieved,  second  and  third  priori¬ 
ties  are  to  fly  to  an  alternate  destination  or 
safely  performing  emergency  procedures.  For 
each  of  these  possibilities  several  subgoals 
exist.  The  main  aspects  for  the  flight  to  any 
destination  can  be  summarized  as  follows: 

•  a  route  from  the  actual  position  to  the 
destination  has  to  be  selected,  which  can 
be 

-  a  standard  route  taken  from  the  na¬ 
vigational  data  base 

-  a  radar  vectored  route  guided  by 
ATC  instructions,  where  the  point 
of  return  into  the  flightplan  is  un¬ 
certain 

-  a  self  generated  route  planned  by 
special  rerouting  algorithms 

•  at  least  one  instrument  approach  proce¬ 
dure  has  to  be  practicable  with  respect  to 
system  status  and  weather  conditions 

•  additionally  the  following  constraints  ha¬ 
ve  to  be  taken  into  account  for  every  leg 
of  the  flight: 

-  appropriate  weather  conditions 

-  possibility  of  navigation  on  the  ba¬ 
sis  of  the  available  radio  nav  facili¬ 
ties 

-  ATC  instructions 

For  the  case  that  there  is  no  solution  for  the 
node  "flight  to  destination"  first  an  alternate 
has  to  be  selected  before  it  can  be  treated  in 
the  same  manner  as  the  destination.  So  the 
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selection  of  an  alternate  destination  is  another 
major  aspect  of  replanning  the  flight. 

Thus,  the  ASPIO  module  for  situation  assess¬ 
ment  and  planning  can  be  divided  into  several 
homogeneous  submodules  presented  in  figure 
4  and  explained  in  the  following  paragraphs. 
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Figure  4 :  Structure  of  the  situation  assessment 
and  flight  planning  module 

3 2.  Situation  assessment  as  application  of 
problem  reduction 

As  mentioned  before,  problem  reduction  is 
used  for  situation  assessment.  An  excerpt  of 
the  knowledge  base  used  for  situation  assess¬ 
ment  has  been  given  in  figure  3.  The  technique 
consists  of  dividing  an  initial  problem  ini'  a 
set  of  subproblems  or  subtasks.  The  knowled¬ 
ge  representation  as  AND/OR  graph  is  easing 
the  application  of  problem  reduction. 

In  [5]  it  is  shown,  that  each  node  of  an 
AND/OR  graph  is  solved  if 

-  it  is  an  OR  node  and  one  of  its  suc¬ 
cessors  is  solved 

-  it  is  an  AND  node  and  all  of  its  suc¬ 
cessors  are  solved 

-  it  is  a  primitive,  which  is  solved. 

If  no  solution  for  a  node  can  be  found,  the  next 
higher  OR  node,  has  to  be  solved.  Thus,  alter¬ 


natives  can  be  acquired  by  processing  a  situa¬ 
tion  AND/OR  graph.  The  provision  of  alter¬ 
natives  enables  local  conflict  resolution  after 
the  conflict  has  been  detected.  Therefore  the 
searching  process  in  the  AND/OR  tree  is  the 
superior  algorithm  for  conflict  detection  and 
coordination  of  planning,  e.g.  classifying  the 
detailed  needs  for  planning. 

The  searching  strategy  should  be  chosen  with 
respect  to  computing  time  and  effort,  so  that 
often  a  heuristical  approach  is  recommended 
[6][7].  In  order  to  apply  a  certain  strategy  a 
sequence  for  processing  the  successors  of  a 
node  has  to  be  defined.  The  selection  of  the 
"next  best  alternative"  as  the  next  OR  succes¬ 
sor  to  be  processed  is  easy,  if  a  situation  inde¬ 
pendent  ranking  can  be  found.  However,  most 
basic  flightplan  modifications,  including  alter¬ 
nate  and  route  selection,  are  strongly  depend¬ 
ent  on  the  actual  situation.  In  this  case  the 
evaluation  of  alternatives  has  to  consider  the 
pilot’s  wishes  as  well  as  the  actual  system  and 
environmental  state,  which  might  be  fuzzy  or 
uncertain. 

33.  Basic  flightplan  modifications 

33.1.  Selection  of  an  alternate  destination 

If  the  node  "flight  to  destination"  cannot  be 
solved,  the  best  alternate  has  to  be  selected. 
Since  the  flight  planning  aid  is  to  support  the 
pilot,  a  ranking  list  of  practicable  alternate 
destinations  is  generated.  The  pilot  has  the 
final  choice  after  the  system  has  evaluated 
each  of  them  and  has  presented  them  to  the 
pilot  in  ranking  order. 

There  are  a  number  of  criteria  to  be  conside¬ 
red  for  the  evaluation  of  the  alternate  destina¬ 
tion,  concerning 

-  runway  length 

-  weather  conditions  with  respect  to 
wind,  ceiling  and  visibility 

-  radio  aids 


-  distance  to  actual  position  and  de¬ 
stination. 

-  servicing  capabilities 

Since  all  of  these  criteria  are  imprecise  or 
fuzzy,  the  evaluation  process  is  based  on  fuzzy 
set  theory  first  introduced  by  [8].  For  each 
criterion  a  membership  function  can  be  defi¬ 
ned.  It  shows  the  degree  of  membership  for  a 
fuzzy  set  of  elements,  which  have  the  attribute 
of  the  predefined  criterion  in  common.  The 
degree  of  membership  is  defined  from  0  to  1.0. 
The  value  of  1.0  is  identical  to  the  highest 
score  of  membership,  e.g.  the  best  criterion  fit. 
Figure  5  shows  a  possible  membership 
function  for  the  criterion  "long  runway". 
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Figure  5 :  Example  for  membership  function 

An  airport  with  a  runway  length  of  3000  m 
would  have  the  membership  degree  of  0.5  wit¬ 
hin  the  fuzzy  set  of  airports  with  "long  run¬ 
ways"  in  this  example.  According  to  former 
explanations  this  membership  function  is  de¬ 
pendent  on  the  actual  situation,  because  the 
minimum  runway  length  varies  due  to  estima¬ 
ted  landing  weight,  aircraft  condition  and  we¬ 
ather  conditions  at  the  airport. 

Since  there  are  more  than  one  evaluation  cri¬ 
teria,  their  degrees  of  memberships  have  to  be 
composed  to  get  a  total  ranking  value  for  each 
alternative.  Considering  that  not  all  criteria 
are  equally  important,  their  degree  of  mem¬ 
bership  is  weighted.  Sufficently  good  results 
have  been  gained  by  just  adding  up  the 


weighted  values  of  degrees  of  membership  in 
order  to  compute  the  total  ranking  value. 
However,  there  are  other  possibilities  [9][10], 
too. 

3  J 2.  Rerouting  algorithms 

For  the  case  that  an  alternate  has  been  selec¬ 
ted  or  the  planned  route  conflicts  with  distur¬ 
bing  events  like  areas  of  bad  weather,  the 
route  has  to  be  modified.  To  offer  a  practica¬ 
ble  new  route,  all  possible  major  conflicts, 
which  cannot  be  solved  locally,  have  to  be 
taken  into  account  by  generating  the  route. 
Thus,  the  rerouting  procedures  are  also  based 
on  a  detailed  situation  analysis  and  evaluation 
of  each  flight-leg  of  the  route. 

A  flight-leg  is  defined  as  the  connection  from 
one  waypoint  to  the  next.  So,  the  principle  is 
to  connect  given  waypoints  and  to  evaluate  the 
resulting  leg.  The  evaluation  process  is  similar 
to  the  explained  alternate  evaluation.  The 
main  aspects  for  route  planning  are 

-  to  keep  away  from  bad  weather 
area 

-  not  to  lose  too  much  time 

-  not  to  consume  too  much  fuel,  at  le¬ 
ast  to  reach  the  destination 

-  to  follow  ATC-instructions 

The  first  aspects  are  considered  by  evaluating 
criteria  like  distance  to  areas  of  bad  weather, 
course  deviation  for  each  leg  and  total  distan¬ 
ce.  The  replanning  area  is  kept  small  ir.  order 
to  avoid  conflicts  with  ATC  constraints. 

It  is  important  for  an  IFR-flight  to  assure  ’ra¬ 
dio  nav’  capability  for  the  flight.  So,  the  possi¬ 
ble  waypoints  are  restricted  to  radio  aids  and 
the  legs  can  only  be  as  long  as  the  beacons  can 
be  kept  in  range.  The  applied  rerouting  algo¬ 
rithms  offer  conventional  ’radio  nav’  as  well  as 
’area  nav’  capability. 
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Only  a  problem  for  ’area  nav’  might  appear,  if 
the  navigational  data  base  does  not  offer  ap¬ 
propriate  waypoints  for  the  area  to  plan  and 
the  planned  route  includes  an  unsoivabie  con¬ 
flict.  For  this  case,  waypoints  must  be  genera¬ 
ted.  This  is  done  by  computing  legs  that  are 
tangent  to  an  estimated  safety  range  around 
the  center  of  the  conflict  area.  Figure  6  shows 
the  planning  on  waypoints  from  the  data  base 
and  generating  new  waypoints. 
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Figure  6 :  Example  for  rerouting  process 


For  the  present  state  of  implementation  only 
one  or  two  new  waypoints  are  considered  for 
each  alternative.  The  evaluation  will  be  ex¬ 
panded  to  any  number  of  waypoints  and  new 
routes  by  improved  algorithms.  The  applica¬ 
tion  of  these  algorithms  will  be  possible  due  to 
permanent  increase  in  computing  power. 
Eventually  a  complete  regional  flight  will  be 
automatically  replanned  in  flight  on  the  basis 
of  knowledge  about  the  destination,  the  actual 
situation  and  an  extended  navigational  data 
base. 

4.  Experimental  testing 

For  the  experimental  test  phase  the  Cockpit 
Assistant  is  implemented  in  a  flight  simulator 
facility  at  the  University  of  the  Armed  Forces 
in  Munich.  Therefore  a  one-seat  fixed  base 
cockpit  with  computer  generated  outside  vi¬ 
sion  and  head  down  display,  artificial  stick 


force  as  well  as  speech  input  and  output  has 
been  used. 

During  the  investigation  nine  professional  pi¬ 
lots  with  a  great  amount  of  experience  perfor¬ 
med  IFR  approaches  to  Munich  airport.  For 
the  evaluation,  special  scenarios  have  been 
simulated  with  and  without  the  support  of  the 
Cockpit  Assistant.  These  scenarios  included 
special  planning  tasks  under  different  condi¬ 
tions. 

One  major  result  was  that  all  recommenda¬ 
tions  of  the  flight  planning  module  were  ac¬ 
cepted.  Besides  this,  the  time  to  decision  after 
the  occurance  of  an  event,  which  required 
replanning,  could  be  significantly  improved. 
Figure  7  represents  the  investigation  results  of 
the  parameter  "time  to  decision". 
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Figure  7 :  Time  to  decision  with  and  without  Cockpit 
Assistant 


5.  Further  development 

These  results,  the  significant  improvements  of 
flight  accuracy  and  the  good  acceptance  by  the 
pilots  [2]  support  future  developments  and 
extension  of  the  assistance  system  functions. 
This  will  lead  to  an  advanced  Cockpit  Assi¬ 
stant  System  called  CASSY  [11].  It  will  be 
developed  for  commuter  aircraft  in  coopera¬ 
tion  with  Domier. 


According  to  the  further  development  of  the 
Cockpit  Assistant  the  situation  assessment 
and  flight  planning  module  will  be  improved 
and  extended.  As  mentioned,  the  rerouting 
algorithms  are  presently  revised  for  offering 
full  route  planning  on  the  basis  of  a  complete 
navigational  data  base,  considering  all  acces- 
sable  information  about  flight  and  system  sta¬ 
tus  and  environmental  conditions.  Additional 
improvements  of  the  evaluation  criteria  will 
conclude  the  lateral  flight  planning  module. 

The  next  step  will  be  3-D  trajectory  planning 
with  regard  to  restricted  areas  and  other  alti¬ 
tude  constraints  from  ATC.  So,  a  conflict  free 
lateral  plan  with  the  most  important  trajectory 
constraints  will  be  generated.  This  can  be  the 
first  step  of  integrating  the  system  into  the 
avionics  of  modem  aircraft.  The  generated 
constraint  list  can  possibly  be  fed  into  a  Flight 
Management  System  to  provide  its  normal 
functions.  Today  this  is  done  by  the  pilot. 
However,  the  main  task  of  the  planning  modu¬ 
le  is  to  provide  the  flightpian  as  input  for  other 
modules  of  the  Cockpit  Assistant. 
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A  further  step  will  be  full  4-D  trajectory  plan¬ 
ning  as  figure  8  shows,  which  represents  the 
complete  structure  of  the  module. 

For  reasons  of  optimization  the  profile  plan¬ 
ning  module  is  divided  into  two  subtasks: 
Firstly,  the  tactical  planning  for  economical 
flightlevel  changes  including  step  climbs  and 
descends  and  secondly,  the  strategical  plan¬ 
ning  of  a  complete  trajectory  using  algorithms 
of  the  tactical  profile  planning  module.  The 
time  planning  has  to  meet  the  requirements  of 
future  Air  Traffic  Management  and  assure  op¬ 
timal  4-D  planning. 

Since  CASSY,  the  advanced  Cockpit  Assi¬ 
stant,  will  include  a  dialogue  manager  to  ma¬ 
nage  the  communication  between  the  crew 
and  the  system  modules,  it  will  be  possible  to 
offer  more  crew  integration  into  the  planning 
process.  This  improvement  will  even  increase 
the  acceptance  of  the  pilots.  Additionally,  the 
situation  assessment  will  be  supported  by  an¬ 
other  new  module  for  recognizing  when  the 
pilot  intentionally  deviates  from  the  flight- 
plan. 
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Figure  8 :  Complete  modular  structure  of  the  situation  assessment  and  flight  planning  module 
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6.  Concluding  Remarks 

The  increasing  complexity  of  aircrafts  and  Air 
Traffic  Management  require  extensive  assi¬ 
stance  for  the  cockpit  crews.  Therefore,  a 
Cockpit  Assistant  has  been  developed  and  a 
computer  aid  for  flight  planning  tasks  has  been 
integrated. 

Because  of  the  results  of  the  experimental 
investigation  the  further  development  of  the 
system  will  be  driven  forward.  Due  to  its  over¬ 
all  structure  and  the  big  amount  of  included 
features  CASSY  could  be  a  well  qualified  air¬ 
borne  assistant  for  crews,  ATC,  companies 
and  their  ground  based  computer  facilities. 


Figure  9 :  Modular  structure  of  the  Assistant  for 
Single  Pilot  IFR  Operation  ASPIO 
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SUMMARY 

In  a  previous  paper  [8],  the  Event-Step  Algorithm 
(ESA)  was  presented  as  an  efficient  path  planning 
algorithm  to  avoid  dynamic  obstacles.  Dynamic 
obstacles  are  defined  as  obstacles  that  move  and/or 
distort  over  time.  This  paper  looks  at  the  algorithm 
more  closely  and  compares  it  to  other  path  planning 
algorithms.  Specifically,  Grid  Search,  Voronoi 
Graph  and  Visibility  Graph  methods  are  considered. 
It  shows  that  the  ESA  offers  advantages  over  these 
methods  and  is  a  generalization  and  improvement  of 
the  Visibility  Graph  method.  A  summary  of  the 
ESA  is  presented. 

1.  INTRODUCTION 

There  is  a  strong  desire  to  build  computer-controlled 
robotic  vehicles  that  can  perform  a  variety  of  tasks. 
For  example,  robotic  land  vehicles  can  be  used  to 
penetrate  hazardous  or  hostile  landscapes  to  collect 
and/or  disseminate  data.  A  military  application  of 
this  type  would  be  to  traverse  the  battlefield  to 
perform  bomb  damage  assessment.  In  a  similar 
manner,  robotic  air  vehicles  could  fly  in  and  around 
the  affected  areas  to  collect  pertinent  data.  In  order  for 
the  vehicle  to  search  the  region  unassisted  by  human 
operators,  it  needs  to  be  able  to  sense  its  local 
environment  to  determine  where  it  is,  where  it  needs 
to  go  and  what  obstacles  are  in  its  way.  Once  the 
vehicle  determines  this,  it  then  needs  to  generate  a 
path  that  will  get  it  from  its  current  location  to  its 
destination  while  avoiding  the  obstacles  in  its  way. 
This  environment  sensing  and  path  planning  are  two 
distinct  tasks  that  constitute  route  planning.  In 
general,  these  two  tasks  must  be  done  continually 
since  there  are  always  errors  in  sensing  and  the 
environment  is  likely  to  change  over  time. 
Developing  methods  to  sense  and  interpret  the 
environment  is  referred  to  as  perception  and  is 
obviously  a  function  of  the  sensor(s)  used. 
Perception  remains,  to  date,  an  extremely  challenging 
problem  that  has  not  been  solved.  In  fact,  it  is  not 
even  understood  how  perception  by  animals  and 
humans  is  accomplished.  Significant  breakthroughs 
in  sensor  technology  and  sensor  processing  are  critical 


to  the  success  of  this  problem.  These  technologies 
are  being  developed  under  various  other  projects. 
Although  sensing  is  a  critical  aspect  of  route 
planning,  it  will  not  be  addressed  in  this  paper. 
Instead,  we  will  focus  on  the  task  of  path  planning  by 
assuming  that  we  are  furnished  with  the  vehicle's 
location,  desired  destination  and  the  location,  size  and 
shape  of  all  obstacles  in  the  region.  Additionally,  we 
will  assume  that  if  any  of  the  obstacles  are  moving, 
they  are  moving  with  constant  speed  and  direction  and 
we  are  provided  this  information  as  well.  Clearly, 
these  are  big  assumptions  but  they  allow  us  to  focus 
on  what  issues  arise  once  this  data  is  provided.  We’ 
will  show  that  even  when  all  this  information  is 
provided,  path  planning  is  still  a  sophisticated  and 
formidable  problem.  We  will  also  show  that  the 
Event-Step  Algorithm  offers  many  advantages  over 
the  other  methods  in  addressing  the  path  planning 
problem  with  moving  obstacles. 

2.  STATEMENT  OF  THE  PROBLEM 

Let  us  first  define  the  path  planning  problem  in 
general  terms.  Consider  figure  2-1,  which  shows  a 
two-dimensional  example.  The  planning  region  is 
the  area  encompassing  the  vehicle's  initial  location, 
the  desired  destination  and  all  obstacles  considered. 
Assume  the  vehicle  is  located  a  point  A  and  is  trying 
to  determine  an  optimal  path  to  point  B.  The  shaded 
regions  are  (stationary)  obstacles  in  the  region  which 
must  be  avoided.  The  bold  path  in  figure  2-1  is  the 
optimal  path  for  this  problem.  We  define  the  optimal 
path,  in  this  context,  to  mean  the  shortest  distance 
path  from  the  current  position  of  the  vehicle  to  the 
destination  which  avoids  all  obstacles.  Thus,  the 
problem  is  to  devise  an  algorithm  which  will  generate 
the  optimal  path  which  will  get  the  vehicle  to  its 
desired  destination  while  avoiding  all  potentially 
moving  obstacles.  In  general,  there  may  be  multiple 
(possibly,  infinite)  optimal  paths,  in  which  case  we 
assume  that  any  one  of  them  is  a  solution.  Note  that 
when  all  the  obstacles  are  stationary,  the  problem  is 
very  similar  to  finding  the  optimal  path  through  a 
maze. 


3.  GENERAL  APPROACH  TO  PATH 
PLANNING 
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In  general,  all  of  the  existing  methods  of  path 
planning  divide  the  problem  into  two  phases.  In  the 
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Figure  2-1.  Planning  problem  with  stationary 
obstacles.  The  bold  line  is  the  optimal  path. 


first  phase,  a  (usually  finite)  search  space  is  generated. 
This  search  space  consists  of  all  the  possible  paths 
that  will  be  considered.  This  search  space  is 
represented  as  a  graph.  Keep  in  mind  that  the  search 
space  of  the  original  problem  is  infinitely  large  since 
there  are  infinitely  many  ways  of  getting  to  the 
destination.  Clearly,  if  an  optimal  path  is  to  be 
found,  then  it  must  exist  within  the  created  search 
space.  There  are  three  common  ways  to  build  this 
search  space:  Voronoi  graphs.  Grids,  and  Visibility 
graphs.  Once  the  search  space  is  created,  the  second 
phase  is  to  navigate  through  this  space  (i.e.,  graph) 
searching  for  an  optimal  path.  The  usual  method  of 
navigation  is  a  form  of  best-first  search.  However, 
since  a  graph  is  being  searched,  uninformed  methods 
such  as  depth-first  and  breadth-first  search  as  well  as 
partially-informed  methods  such  as  hill-climbing 
could  also  be  used,  although  they  would  not,  in 
general,  be  as  efficient.  The  three  main  methods  of 
generating  the  search  space  are  discussed  in  this  paper. 
A  detailed  discussion  of  hill-climbing,  best-first, 
depth-first  and  breadth-first  search  can  be  found  in  [7, 
10]. 

3.1  Voronoi  Graphs 

Voronoi  graphs  are  made  by  placing  a  node  at  every 
"T"  intersection  of  the  corresponding  Voronoi 
diagram.  A  “T”  intersection  is  simply  where  three 
lines  meet  The  Voronoi  diagram  is  the  set  of  points 
that  are  equidistant  from  two  or  more  obstacles.  The 
(imaginary)  borders  of  the  operating  region  are  treated 
as  obstacles  as  well  in  constructing  the  Voronoi 
diagram.  The  resulting  Voronoi  diagram  for  figure  2- 
1  is  shown  in  figure  3.1-1.  The  corresponding 
Voronoi  graph  is  shown  in  figure  3.1-2.  Note  that 
the  "T”  intersections  become  nodes  in  the  graph  and 
the  locus  of  points  between  them  become  edges.  A 
more  detailed  discussion  of  Voronoi  graphs  is  given 
in  [4],  A  nice  feature  of  the  Voronoi  graph  is  that 


since  there  are  only  a  few  nodes  generated,  the  entire 
graph  may  be  rapidly  searched.  However,  as  pointed 
out,  if  the  search  space  docs  not  include  the  optimal 
path,  then  no  amount  of  search  will  find  it.  In 
general,  Voronoi  graphs  do  not  include  an  optimal 
path.  Figure  3.1-3  shows  the  “optimal”  path  that 
would  be  generated  for  the  problem  in  figure  2-1. 
Comparing  the  paths,  we  see  there  are  many  needless 
"kinks"  in  the  Voronoi  paths.  Worse  yet,  since  the 
Voronoi  graph  is  a  function  of  the  distance  between 
the  obstacles,  progressively  inferior  paths  result  when 
the  obstacles  are  further  apart.  This  problem  can 
easily  be  seen  by  drawing  the  Voronoi  diagram  for  a 
single  obstacle  as  shown  in  figure  3. 1  -4.  This  figure 
shows  an  obstacle  that  is  barely  on  the  direct  path 
from  A  to  B.  However,  instead  of  steering  the 
vehicle  slightly  off  the  direct  path  to  avoid  the 
obstacle,  it  directs  the  vehicle  along  the  much  longer 
paths  that  are  equidistant  between  the  obstacle  and  the 
planning  region  borders. 


Figure  3.1  -1 .  Voronoi  diagram  for  figure  2-1 . 


Figure  3.1-2.  Resulting  Voronoi  graph.  Note  the 
nodes  of  the  graph  occur  at  the  "T"  intersections. 


14-3 


Figure  3.1-3.  "Optimal”  path  generated  by  the 
Voronoi  graph.  Note  the  path  has  substantially 
more  kinks  than  the  optimal  path  in  figure  2-1 . 


not  even  produce  optimal  paths  for  two-dimensional 
problems  with  static  obstacles. 

3.2  Grids 

Grids  are  made  by  overlaying  an  array  of  cells  over 
the  planning  region  as  shown  in  figure  3.2-1.  Cells 
that  are  more  than  half  filled  by  an  underlying 
obstacle  are  marked  as  impassable.  Paths  are  then 
found  by  moving  through  adjacent  cells  of  the  grid 
that  are  passable  until  the  cell  containing  the 
destination  is  reached.  Note  that  the  cells  become  the 
nodes  of  the  graph  and  the  cell-to-cell  transitions  are 
the  edges.  The  number  of  cells  used  in  each 
dimension  is  a  parameter  but  a  trade-off  in  time 
versus  storage  and  path  quality  emerges.  Namely,  as 
the  number  of  cells  increases  there  is  more 
opportunity  of  including  the  optimal  path  within  the 
search  space.  However,  more  storage  is  needed  to 
maintain  the  grid  and  more  time  is  required  to  find  the 
path  since  the  search  space  is  larger. 


Figure  3.1-4.  Voronoi  graph  for  a  single  obstacle. 
Note  that  the  path  guides  the  vehicle  far  from  the 
direct  path  even  though  the  obstacle  is  small  and  is 
barely  in  its  path. 


Figure  3.2-1.  Grid  method.  All  cells  that  correspond 
to  the  location  of  an  obstacle  are  marked  as 
impassable. 


Based  on  the  discussion  of  Voronoi  graphs,  one  can 
see  that  the  attempts  to  extend  this  method  to  either 
three-dimensional  worlds  or  moving  obstacles  are 
futile.  In  three-dimensional  worlds,  the  set  of  points 
equidistant  between  two  or  more  obstacles  becomes 
planes  instead  of  lines.  Thus  there  become  infinitely 
many  ways  to  generate  paths  between  any  two 
obstacles.  Moving  obstacles  are  not  handled  either 
because  the  set  of  points  making  up  the  Voronoi 
diagram  is  changing  over  time  and  thus  the 
corresponding  Voronoi  graph  is  changing  as  well. 

Thus  we  see  that  path  planning  algorithms  based  on 
Voronoi  graphs  not  only  do  not  extend  to  three- 
dimensional  or  moving  obstacle  problems,  they  do 


Figure  3.2-2  shows  the  best  path  in  the  search  space. 
Comparing  it  to  figure  2-1  we  see  that  the  path 
created  using  the  grid  method  is  similar  but  a  bit 
more  jagged.  As  the  number  of  cells  increases,  a 
smoother  path,  asymptotically  approaching  the 
optimal  path  in  figure  2-1,  would  emerge.  In  figure 
3.2-3  we  again  use  the  grid  method  but  with  a  larger 
cell  size.  Note  that  previously  passable  gaps  between 
the  obstacles  are  now  lost  and  the  best  path  in  the 
resulting  search  space  is  quite  inferior  to  the  optimal 
path  in  the  original  problem. 
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Figure  3.2-2.  "Optimal"  path  generated  by  the  grid 
method.  Similar  to  the  optimal  path  in  figure  2-1  but 
more  jagged. 


Figure  3.2-3.  "Optimal"  path  using  the  grid  method 
with  larger  cells.  Note  the  substantially  inferior 
path. 


Applying  the  grid  method  to  three-dimensional 
problems  involves  the  use  of  three-dimensional  grids. 
All  other  aspects  of  the  method  remain  the  same.  Of 
course  when  three-dimensional  problems  are 
addressed,  the  number  of  cells  drastically  increases  and 
thus  time  versus  path  quality  becomes  even  more  of 
an  issue. 

In  a  similar  manner,  once  the  obstacles  are  allowed  to 
move,  we  need  to  build  a  sequence  of  grids 
representing  the  position  of  the  obstacles  at  various 
points  in  time.  Thus,  two-dimensional  problems 
require  three-dimensional  arrays  and  three-dimensional 
problems  require  four-dimensional  arrays! 


and  high  processing  capability  to  obtain  fairly 
optimal  paths  in  a  reasonable  time. 

3.3  Visibility  Graphs 

Visibility  graphs  are  made  by  establishing  the 
straightline  visibility  between  the  vertices  of  all 
obstacles  along  with  the  vehicle's  initial  and  desired 
locations.  To  form  this  graph,  the  obstacles  arc 
modeled  as  a  set  of  convex  polygons.  Then,  the  set 
containing  all  of  the  obstacles'  vertices  along  with  the 
vehicle’s  initial  and  desired  locations  become  the 
nodes  of  the  visibility  graph.  The  edges  of  the 
visibility  graph  are  made  by  determining  all  the 
straight,  uninterrupted  paths  between  these  nodes.  An 
uninterrupted  path  is  one  that  doesn’t  cross  or  clip  any 
obstacle.  The  visibility  graph  for  figure  2-1  is  shown 
in  figure  3.3-1.  Note  that  the  optimal  path  is 
contained  within  the  visibility  graph.  This  was  not 
coincidental.  In  fact,  it  can  been  proven  that  the 
optimal  path  for  two-dimensional  problems  is  always 
contained  within  the  visibility  graph.  The  proof  is 
based  on  imagining  tying  a  rubber  band  between  the 
nodes  A  and  B.  The  rubber  band  is  then  stretched  by 
“threading”  it  around  the  obstacles  until  it  lays  flat 
without  overlapping  any  obstacle.  It  should  be 
intuitively  clear  that  any  optimal  “threading”  of  the 
rubber  band  will  coincide  with  the  edges  of  the 
visibility  graph.  Generation  of  the  optimal  path, 
along  with  the  fact  that  visibility  graphs  are 
reasonably  small,  makes  them  a  very  attractive 
method  for  solving  two-dimensional  (static)  obstacle 
avoidance  problems. 


its  optimal  path.  This  optimal  path  Is  identical  to  the 
path  in  ligure  2-1. 

However,  things  get  deceptively  hard  when  one 
attempts  to  extend  visibility  graphs  to  either  three- 
dimensional  or  moving  obstacle  problems.  At  first, 
it  would  seem  that  visibility  graphs  could  handle 
three-dimensional  obstacles  by  simply  treating  them 


As  a  result,  path  planning  algorithms  based  on  the 
grid  method  require  both  extremely  large  memories 
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as  polyhedrons,  using  all  its  vertices  as  the  nodes  and 
all  the  uninterrupted  paths  between  them  as  edges. 
Unfortunately,  the  optimal  path  would  not,  in 
general,  be  contained  in  this  graph.  As  an  example, 
consider  the  problem  where  the  vehicle  is  sitting  on 
top  of  a  large  rectangular  block  and  is  trying  to  find 
the  optimal  path  to  the  floor  in  front  of  the  vehicle. 
The  optimal  path  is  to  simply  go  straight  ahead  to 
the  edge  of  the  block  and  then  move  down  to  the 
floor.  However,  this  path  would  not  be  included  in 
the  visibility  graph.  Instead,  the  vehicle  would  have 
to  first  move  to  one  of  the  upper  comers  of  the  block, 
then  down  to  the  floor,  and  then  move  back  to  the 
desired  spot  on  the  floor.  As  a  result,  three- 
dimensional  problems  are  not  handled  by  the 
visibility  graph  method. 

Visibility  graphs  do  not  handle  moving  obstacles  for 
a  similar  reason  that  Voronoi  graphs  do  not.  Since 
the  visibility  graph  changes  over  time  as  the 
obstacles  move,  one  cannot  build  a  static  graph  and 
expect  it  to  be  useful  in  a  dynamic  environment. 

So  we  see  that  while  visibility  graphs  are  an  excellent 
choice  for  planning  problems  where  the  obstacles  are 
static  and  two-dimensional,  they  are  deficient  when 
the  obstacles  are  moving  and/or  three-dimensional. 

4.  THE  EVENT-STEP  ALGORITHM 

It  will  be  shown  that  the  Event-Step  Algorithm 
(ESA)  is  a  generalization  and  improvement  of  the 
visibility  graph  method.  Namely,  the  ESA  allows 
dynamic  and/or  three-dimensional  obstacles  but  when 
the  obstacles  are  two-dimensional  and  static,  the  ESA 
reduces  to  the  visibility  graph  method,  except  it 
builds  a  smaller  (implicit)  graph.  In  addition,  we 
claim  that  this  smaller  graph  contains  the  optimal 
path.  Although  we  do  NOT  claim  to  produce  the 
optimal  path  for  moving  obstacle  problems,  the  paths 
generated  are  of  high  quality.  In  actuality,  finding  the 
optimal  path  for  dynamic  obstacle  problems  has  been 
shown  to  be  NP-Hard.  However,  the  ESA 
demonstrates  that  by  forgoing  optimality,  it  can 
generate  nearly  optimal  paths  for  dynamic  obstacle 
problems  in  polynomial  time.  In  fact,  it  will  be 
shown  that  the  ESA  can  handle  dynamic  obstacles 
without  introducing  significantly  more  time 
complexity  than  the  static  obstacles  case. 

Details  of  the  ESA  are  given  in  Silbert  [8],  but  are 
summarized  here.  One  of  the  key  aspects  of  the  ESA 
is  that  the  search  space  graph  is  built  implicitly,  as 
needed,  instead  of  built  all  at  once,  staticly.  The  part 
of  the  graph  that  is  required  is  determined  by 
computing  intercepts.  To  explain  the  ESA,  let  us 
use  the  two-dimensional  example  shown  in  figure  4- 
1.  The  figure  shows  the  initial  vehicle  location,  the 
desired  destination  and  an  intervening  obstacle. 
Assume,  for  now,  that  the  obstacle  is  stationary. 


Figure  4-1 .  A  simple  planning  problem  with  a 
stationary  obstacle. 


Like  the  visibility  graph  method,  all  obstacles  are 
modeled  as  convex  polygons.1  The  algorithm  first 
checks  to  see  if  any  obstacles,  i.e.,  polygons,  are  in 
the  direct  path  to  the  desired  location.  For  the  given 
example,  the  obstacle  is  on  this  direct  path.  The 
ESA  then  computes  the  clockwise  and  counter¬ 
clockwise  paths  around  the  obstacle.  To  go 
clockwise  around  the  obstacle,  the  most  counter¬ 
clockwise  vertex  of  the  polygon  is  found  and  used  as 
the  new  (intermediate)  destination  (see  figure  4-2). 
This  counter-clockwise  vertex  is  the  one  which  yields 
the  most  left-hand  turn  away  from  the  direct  path  to 
the  destination. 


Figure  4-2.  Determining  the  vertex  of  the  obstacle 
that  yields  the  most  counter-clockwise  turn  from  the 
direct  path  to  B. 


1  As  pointed  out  in  [8],  requiring  all  polygons  to  be 
convex  is  not  a  real  restriction  since  any  arbitrary 
(e.g.,  concave)  polygon  can  be  represented  as  a  set  of 
one  or  more  convex  polygons. 
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Then  by  constructing  the  line  from  this  vertex  to  the 
final  destination,  a  determination  is  made  whether  to 
move  to  the  next  clockwise  vertex  or  to  move  directly 
to  the  final  destination  (figure  4-3).  This 
determination  is  made  by  simply  choosing  the  one 
which  yields  the  lesser  clockwise  turn.  If  the  final 
destination  requires  the  lesser  turn,  we  then  have  the 
clockwise  path  around  the  obstacle.  If  the  next 
clockwise  vertex  yields  the  lesser  tum,  we  move  to 
that  vertex  and  repeat  the  process.  The  final 
clockwise  path  around  the  obstacle  is  shown  in  figure 
4-4. 


choose  the  smaller  one,  yielding  the  same  optimal 
path  as  the  visibility  graph  method. 

Multiple  obstacles  are  handled  by  recursively  finding 
these  clockwise  and  counter-clockwise  paths  for  each 
obstacle  as  it  is  encountered.  Namely,  the  ESA  finds 
the  clockwise  path  around  the  first  obstacle 
encountered.  As  it  generates  this  clockwise  path,  it 
checks  to  see  if  any  other  obstacles  are  encountered. 
If  an  obstacle  is  encountered,  the  ESA  recursively 
applies  itself  to  solve  this  subproblcm.  Similar 
processing  then  occurs  for  the  counter-clockwise  path 
around  the  original  obstacle.  As  pointed  out  in  [8], 


Lesser  clockwise  turn 


Figure  4-3.  Determining  the  lesser  clockwise  turn 
around  the  obstacle. 


Figure  4-4.  Final  clockwise  path  around  the 
obstacle. 


Going  counter-clockwise  around  the  obstacle  is 
handled  similarly.  Namely,  as  shown  in  figure  4-5, 
the  most  clockwise  vertex  is  found  and  then  we 
choose  the  lesser  counter-clockwise  vertex  each  time. 
The  counter-clockwise  path  is  shown  in  figure  4-6.  If 
this  were  the  only  obstacle,  the  ESA  would  then 
simply  compare  the  distances  of  these  two  paths  and 


simply  applying  this  obstacle  avoidance  method  to 
each  subproblem  can  lead  to  inefficiencies  in  the 
overall  solution.  Also  in  [81,  this  problem  is 
remedied  by  building  and  evaluating  the  extra  paths 
that  are  made  by  including  the  maximal  deviate 
points.  The  maximal  deviate  points  are  those  points 
that  deviate  the  furthest  from  the  direct  path  to  the 
destination. 


Figure  4-5.  Determining  the  vertex  of  the  obstacle 
yielding  the  most  clockwise  turn  from  the  direct  path 
fo  B. 


Figure  4-6.  Final  counter-clockwise  path  around  the 
obstacle. 
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Figure  4-7  shows  the  result  of  applying  the  ESA  to 
the  original  problem  in  figure  2-1.  The  dotted  paths 
are  the  ones  that  were  built  and  evaluated  prior  to 
selecting  the  optimal  path.  Note  that  the  dotted  lines 
make  up  a  subset  of  the  visibility  graph.  Namely,  in 
general,  there  are  two  classes  of  lines  that  occur  in  the 
visibility  graph  but  are  not  generated  by  the  ESA:  1) 
lines  that  are  not  locally  tangent  to  the  obstacles  and 
2)  lines  to  and  between  obstacles  that  are  so  far  off 
the  direct  path  that  they  need  not  be  considered.  A 
line  is  locally  tangent  to  two  or  more  polygons  if  it 
intercepts  at  least  one  vertex  of  each  polygon  but  does 
not  penetrate  it  (i.e.,  does  not  pass  through  the 
interior  of  the  polygon).  Since  the  optimal  path 
includes  neither  of  these  line  classes,  we  are  sure  that 
the  optimal  path  is  not  discarded  by  the  ESA.  In 
other  words,  the  ESA  will  generate  and  return  the 
optimal  path  for  static  two-dimensional  problems 
without  generating  all  the  nodes  and  edges  of  the 
visibility  graph. 


Figure  4-7.  The  resulting  ESA  graph  for  figure  2-1 
with  its  optimal  path.  Note  the  reduction  in  the 


number  of  edges  generated  relative  to  the  visibility 
graph  in  figure  3.3-1 .  Like  the  visibility  graph, 
however,  the  optimal  path  is  identical  to  the  path  in 
figure  2-1. 

Moving  obstacles  are  handled  by  the  ESA  in  an 
analogous  way  except  each  vertex  of  the  polygon  is 
assumed  to  be  moving  with  constant  speed  and 
direction.  Therefore,  given  the  speed  of  the  vehicle, 
the  location  of  each  vertex  ,._«n  intercept  can  be 
determined.  The  time  at  which  the  vehicle  arrives  at 
the  moving  vertex  is  computed  as: 

(s*t)2  =  (x,  +  vx*t  -  x)2  +  (yt  +  Vy*t  -  y)2 

where  xj.yj  is  the  ith  vertex  of  the  polygon, 

vx,vy  are  the  X  and  Y  components  of  the 
polygon’s  velocity  vector 
x,y  is  the  location  of  the  vehicle 
s  is  the  speed  of  the  vehicle 


and  t  is  the  computed  time  when  the  vehicle 
arrives  at  the  polygon's  ith  vertex. 
Note  that  this  equation  is  based  on  the  Pythagorean 
Theorem  for  right  triangles.  Using  this  equation,  the 
ESA  determines  the  clockwise  and  counter-clockwise 
paths  around  the  moving  obstacle  as  before.  In 
figures  4-8  and  4-9,  we  again  have  a  single  obstacle 
except  this  time  it  is  moving  in  a  southeasterly 
direction.  Figure  4-8  shows  the  resulting  clockwise 
path  around  the  obstacle.  Figure  4-9  is  the  resulting 
counter-clockwise  path. 


Figure  4-8.  Final  clockwise  path  around  the 
moving  obstacle. 


The  ESA  can  also  be  extended  to  a  special  case  of 
three-dimensional  obstacles.  These  obstacles  are  ones 
that  have  some  arbitrary  polygonal  cross-section  (as 
already  assumed)  but  have  a  specified  lower  and  upper 
height.  This  transforms  the  obstacle  model  from  a 
set  of  convex  polygons  to  a  set  of  generalized  convex 
“cylinders”.  Using  these  generalized  cylinders  as  the 
three-dimensional  model  for  obstacles,  we  see  there 
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are  four  locally  minimal  ways  to  go  around  it: 
clockwise  in  the  horizontal  and  vertical  planes  and 
counter-clockwise  in  the  horizontal  and  vertical 
planes.  The  clockwise  and  counter-clockwise  paths  in 
the  horizontal  are  the  same  two  paths  found  for  the 
two-dimensional  problems.  One  can  think  of  the 
path  that  goes  clockwise  in  the  vertical  plane  as 
going  over  the  obstacle  and  counter-clockwise  in  the 
vertical  plane  as  going  under  the  obstacle.  Thus,  the 
same  strategy  used  to  move  around  the  obstacles  is 
used  to  move  over  and  under  them  as  well.  Note  that, 
unlike  the  visibility  graph  method,  the  strategy  used 
by  the  ESA  would  correctly  solve  the  problem 
presented  earlier  where  the  vehicle  is  sitting  on  a 
block  and  is  trying  to  get  to  the  floor  directly  in  front 
of  it.  The  ESA  does  not  strictly  depend  on  the 
vertices  the  way  the  visibility  graph  method  docs.  It 
only  considers  clockwise  and  counter-clockwise 
movement  around  the  obstacles.  Also  note  that  it  is 
important  to  use  only  the  special  case  of  three- 
dimensional  obstacles  previously  defined  since  only 
they  have  the  property  of  having  four  locally  minimal 
paths  around  it.  Namely,  once  slopes  and/or  curves 
arc  included  in  the  obstacle  model,  there  may  be  many 
locally  minimal  paths  around  them.  A  worst  case 
example  is  modelling  an  obstacle  as  a  sphere  which 
has  an  infinite  number  of  locally  minimal  paths 
around  it. 

5.  ANALYSIS  OF  THE  ESA 

Since  the  ESA  has  been  shown  to  be  an  extension 
and  improvement  over  the  visibility  graph  methods, 
it  makes  it  easier  to  quantify  its  performance.  The 
size  of  the  visibility  graph  is  a  function  of  the 
number  of  obstacles  and  the  number  of  vertices  per 
obstacle.  The  analysis  will  make  use  of  the  standard 
big  “O”  notation  found  in  [1],  For  simplicity, 
assume  there  are  N  obstacles  each  containing  M 
vertices.  Therefore,  there  are  N*M  +  2  nodes  in  the 
visibility  graph  (Note  the  initial  and  desired  locations 
of  the  vehicle  are  treated  as  nodes).  Thus,  in  worst 
case  there  are  (1/2>((N*M  +  2)2  -  (N«M  +  2))  edges  in 
the  graph.  Since  the  time  complexity  is  directly 
proportional  to  the  number  of  edges  in  the  graph,  the 
complexity  is  0((N*M)2).  Thus  the  worst  case  time 
complexity  for  the  ESA  for  static,  two-dimensional 
problems  is  0((N*M)2).  However,  since  the  ESA 
does  not  build  the  entire  visibility  graph,  the  actual 
number  of  edges  is  much  smaller.  When  the  ESA  is 
applied  to  moving  obstacle  problems,  we  see  that 
there  arc  really  no  extra  edges  generated  and  the  new 
position  of  the  node  is  computed  in  constant  time. 
Thus,  this  is  the  worst  case  time  complexity  for  all 
(i.e.,  both  static  and  dynamic)  two-dimensional 
problems.  Note  how  this  contrasts  against  the  other 
methods  presented.  Recall  that  the  Voronoi  and 
visibility  graph  methods  simply  don’t  handle  moving 
obstacles  while  the  grid  method  requires  significantly 
more  memory  and  processing. 


When  dealing  with  three-dimensional  obstacles,  a 
similar  result  occurs.  The  ESA  needs  to  generate  the 
extra  over  and  under  the  obstacle  edges  but 
characterizing  the  added  complexity  becomes  a  bit 
unclear.  To  go  over  these  generalized  cylinders 
requires  two  nodes.  Similarly,  going  under  also 
requires  two  nodes.  Thus  we  see  that  four  extra  nodes 
are  effectively  added  to  each  obstacle.  Since  this  is  a 
constant,  we  can  ignore  these  extra  nodes  in  the  order 
of  lime  complexity  calculation.  Thus  we  see  that  the 
time  complexity  to  handle  three-dimensional 
obstacles  remains  0((N*M)2).  Therefore,  we  still  see 
substantial  benefit  of  the  ESA  to  the  other  methods 
mentioned.  Recall  that  the  Voronoi  and  the  visibility 
graph  methods  do  not  extend  to  three-dimensional 
problems  and  the  grid  method  requires  one  to  use 
substantially  more  memory  and  processing. 

6.  CONCLUSION 

The  ESA  is  a  powerful  path  planning  algorithm  that 
requires  only  moderate  memory  size  and  processing 
power  to  execute.  Furthermore,  when  the  problem 
involves  static,  two-dimensional  problems,  the  ESA 
will  find  the  optimal  path.  When  the  problem 
involves  dynamic  obs-.acles,  the  guarantee  of 
optimality  is  lost  but  the  ESA  easily  generalizes  to 
th^se  problems  and  requires  negligibly  more 
p.ocessing  to  solve  them.  It  should  be  noted  that 
finding  the  optimal  path  for  dynamic  obstacle 
problems  has  been  shown  to  be  NP-Hard.  Thus,  the 
ESA,  like  any  other  polynomial  algorithm  can  not 
possibly  find  the  optimal  solution  for  all  geometries. 
However,  the  paths  found  by  the  ESA  are  of  high 
quality  and  are  found  quickly.  Thus  the  ESA  forgoes 
optimality  but  generates  nearly  optimal  paths  in 
polynomial  time.  Finally,  a  special  case  of  three- 
dimensional  obstacle  avoidance  problems  can  also  be 
handled  by  the  ESA  without  much  more  processing 
requirements. 
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1.  SUMMARY 

The  evolution  of  present  day  Air  Traffic  Management  (ATM) 
towards  an  integrated  Air  Traffic  Management  will  lead  to  the 
introduction  of  computer  based  planning  systems  on  the 
ground  side,  which  communicate  with  advanced  Flight 
Management  Systems  onboard  the  aircraft  via  automatic  data 
link.  An  experimental  Flight  Management  System  (EFMS)  is 
under  development  in  the  frame  of  the  PHARE  program  for 
research  into  future  ATM  concepts.  This  EFMS  will  have  the 
capability  to  predict  a  4-dimensional  trajectory  according  to  a 
set  of  constraints  given  by  an  ATC  planning  computer  on  the 
ground.  It  will  negotiate  this  trajectory  with  ATC  \  ia  data  link 
and  will  generate  appropriate  guidance  commands  for  the 
autopilol/autothrottle  system  to  steer  the  aircraft  along  this 
trajectory.  This  paper  describes  briefly  the  functionality  of  the 
EFMS  and  then  concentrates  on  the  planning  strategy  for  the 
generation  of  a  trajectory  from  the  departure  to  the  destination 
airport  which  meets  the  defined  constraint  attributes. 

2.  INTRODUCTION 

Increasing  numbers  of  transport  aircraft  are  being  supplied 
with  or  else  retrofitted  with  Flight  Management  Systems 
(FMS).  Their  installation  offers  aircraft  operators  the  potential 
for  cost  savings  by  providing  guidance  to  trajectories 
optimised  to  their  operating  criteria.  However,  in  many  parts 
of  Europe,  the  potential  advantages  are  only  partially  realised 
due  to  external  constraints  placed  upon  aircraft  speed/height 
trajectories  by  the  Air  Traffic  Services.  Such  constraints 
normally  result  because  the  density  of  Air  Traffic  prevents 
ATC  offering  aircraft  their  desired  flight  trajectories.  As  the 
density  of  traffic  increases  towards  the  start  of  the  21st 
Century,  these  constraints  are  very  likely  to  become  more 
severe. 

The  opportunity  exists  for  significant  improvement  in  capacity 
and  efficiency  of  the  present  day  Air  Traffic  Management 
(ATM)  system  by  the  much  closer  integration  of  airborne  and 
ground  based  computer  systems. 

The  picture  emerging  is  of  a  future  ATM  system  using  the 
predicted  flight  trajectory  information  of  participating  aircraft, 
to  delect  and  resolve  conflicts  over  substantially  greater  time 
horizons  than  is  currently  the  case.  A  process  of  negotiation 
might  take  place  between  ground  and  airborne  systems  to 
establish  a  3-  or  4-dimensional  flight  path  to  be  flown.  The 
trajectory  might  conceivably  be  expressed  as  a  4-dimensional 
volume  of  airspace  (a  'bubble'  moving  in  time),  within  which 
the  aircraft  would  be  required  to  remain.  The  exact  dimensions 
might  depend  on  factors  such  as  traffic  density  at  that  time. 
This  could  allow  aircraft  to  optimise  their  exact  trajectories 


while  being  flown,  thus  taking  into  account  changes  in 
meteorological  conditions  or  mission  priorities. 

Such  a  concept  requires  the  development  of  many  techniques 
not  currently  in  operational  use  within  the  Air  Transport 
Industry.  Examples  include  flight  trajectory  data  exchange 
using  evolving  air-ground  data  links,  4-dimensional  trajectory 
prediction  and  guidance,  conflict  detection  and  resolution 
techniques  to  mention  only  a  few. 

Eurocontrol  Member  Slates  have  agreed  to  develop  the  means 
for  executing  research  on  these  topics  under  the  umbrella  of 
the  ‘Programme  for  Harmonised  ATM  Research  in 
EUROCONTROL'  (PHARE).  This  initiative  will  effectively 
combine  complementary  expertise  available  in  the  member 
t  gani-ations.  The  ultimate  objective  will  be  a  full 
demo  .  -ation  of  an  ATM  system  working  under  the  concepts 
developed  in  the  PHARE  program,  involving  ground  ATC 
simulation  with  simulated,  FMS  equipped  aircraft  followed  by 
trials  employing  fully  equipped  research  aircraft  flying  in  a 
simulated  ATC  environment. 

3.  EXPERIMENTAL  FLIGHT  MANAGEMENT  SYSTEM 
A  common  requirement  of  the  partners  in  the  PHARE 
program  is  an  Experimental  Flight  Management  System 
(EFMS)  [1],  [2],  that  will  serve  as  a  research  tool  to  allow 
development  and  evaluation  of  techniques  and  functions 
mentioned  above.  The  EFMS  will  not  require  the  complexity 
and  integrity  of  full  commercial  equipment  and  many 
functions,  such  as  sensor  management,  are  entirely 
superfluous.  However,  two  issues  are  crucial.  Firstly 
researchers  must,  in  the  light  of  their  experiments,  be  able  to 
develop  and  modify  algorithms  incorporated  in  the  EFMS. 
Secondly,  complementary  research  activities  will  need  to 
exchange  the  products  of  their  work  in  the  form  of  algorithms 
or  software  modules. 

3.1  Interfaces  of  the  EFMS 

The  EFMS  provides  interfaces  to  the  outside  world,  mainly 
pilot,  experimenter.  ATC  and  aircraft,  as  shown  in  Figure  1 . 

The  pilot  communicates  with  the  EFMS  via  a  Control  and 
Display  Unit  (CDU).  which  will  be  utilised  to  enter 
performance  parameters  or  to  assemble  a  list  of  constraints 
defining  the  route  of  flight.  The  Electronic  Flight  Instrument 
System  (EFIS)  will  serve  for  the  graphical  representation  of 
the  predicted  flight  trajectory. 

Before  running  an  experiment  the  experimenter  (Supervisor) 
may  upload  preparation  files  and  modify  certain  experimental 
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parameters  or  select  different  recording  options  via  a  terminal. 

The  ATC  interface  connects  the  EFMS  to  an  automatic  data 
link.  There  will  be  an  automatic  exchange  of  weather  data. 
Onboard  measured  wind,  temperature  and  position  data  wilt  be 
downlinked  to  update  a  weather  data  base  on  the  ground 
which  may  be  used  by  the  EFMS  to  query  the  latest  weather 
data. 

The  aircraft's  prefered  trajectory  planned  to  chosen  mission 
objectives  could  be  negotiated  with  the  ATC  planning 
computer.  ATC  may  send  a  list  of  constraints  at  certain 
waypoints,  which  could  allow  the  respective  aircraft  to  be 
safely  and  efficiently  merged  into  a  dense  flow  of  traffic. 

The  EFMS  receives  the  aircraft's  'State  Vectors'  from  the 
sensor  system  and  delivers  the  'Outer  Loop  Guidance  Vector' 
to  the  aulopilot/autothrottle  system. 

3.2  Major  Processes  of  the  EFMS 

The  internal  structure  of  the  EFMS  is  depicted  in  Figure  2  in 
a  simplified  manner.  All  internal  processes  are  represented  by 
'bubbles'.  Data  stores  are  shown  as  rectangular  boxes. 
Directed  lines  between  processes,  data  stores  and  the  external 
interfaces  indicate  the  flow  of  data. 

Process  1  (Assemble  Constraint  List)  assembles  a  list  of 
constraints  in  chronological  order.  A  constraint  consists  of  a 
waypoint  with  additional  attributes.  For  the  construction  of  a 
constraint  list  the  pilot  may  select  from  the  navigation  data 
base  a  route  or  a  part  of  a  route  by  name  or  as  a  series  of 
waypoints.  Constraints  may  also  be  send  from  ATC  via  data 
link. 

Process  2  (Manage  Performance  Parameters)  generates  a 
list  of  performance  parameters  which  forms  the  'Phase  Table'. 
These  performance  parameters  (  thrust  settings,  climb  speeds, 
cruise  altitude  etc.  )  could  either  be  manually  entered  by  the 
pilot  via  the  CDU  or  could  be  called  up  by  the  pilot  from  a 
'Performance  Handbook'  contained  in  the  data  base  of  the 
EFMS. 

Process  3  (Manage  Mcteo)  retrieves  meteo  data  (wind  and  air 
temperature)  along  the  intended  route  from  a  data  store 
providing  a  meteo  grid  of  the  respective  area.  In  the  Phase  1 
version  of  the  EFMS  the  meteo  grid  will  be  uploaded  by  the 
experimenter  by  means  of  a  preperalion  file  prior  to  the 
experiment.  In  a  later  version  it  will  be  queried  from  the 
meteo  data  base  cm  the  ground  via  data  link. 

Process  4  (Predict  Trajectory)  generates  the  'Proposed 
Trajectory'  composed  of  the  lateral  route  and  the  vertical 
profile.  Major  inputs  to  this  process  are  a  list  of  constraints 
and  a  list  of  performance  parameters  entered  by  the  pilot  as 
well  as  meteo  information  along  the  route.  The  state  vectors 
arc  used  to  define  the  initial  planning  conditions  (aircraft 
airborne  or  on  the  ground).  The  prediction  of  the  lateral  route 
is  based  on  the  sequence  of  waypoints  contained  in  the 
constraint  list.  The  vertical  profile  is  made  up  of  a  scries  of 
flight  phases  defined  by  the  'Phase  Table’  set  up  by  the  pilot. 

Process  5  (Negotiate  Contract)  sends  a  description  of  the 
'Proposed  Trajectory',  generated  by  process  4,  down  to  ATC, 
if  the  pilot  requires  a  clearance  for  that  trajectory.  The  process 
receives  a  tube  description  defined  by  ATC.  which  is  based 


upon  the  requested  trajectory  giving  4D  tolerances  around  the 
trajectory  that  provide  a  margin  to  allow  for  flight  technical 
error,  meteo  changes,  performance  variations,  etc..  Trajectory 
and  tube  description  are  also  made  available  for  display  to  the 
pilot  Trajectory  and  tube  are  then  activated,  if  the  pilot  agrees 
with  the  tube  assigned  by  ATC. 

Process  6  (Guide  Aircraft  through  Tube)  generates  guidance 
commands  taking  the  'Active  Trajectory'  and  the  aircraft  state 
as  inputs.  These  guidance  commands  are  then  fed  into  the 
autopilot/autothrottlc  system  to  steer  the  aircraft  along  the 
trajectory.  The  position  of  the  aircraft  within  the  'Active 
Tube'  is  monitored  and  a  warning  is  issued  to  the  pilot,  if  the 
aircraft's  flight  path  attempts  to  infringe  the  tube. 

4.  PREDICTION  OF  4D-TRAJECTORIES 
A  major  function  of  the  EFMS  is  to  generate  a  4D  trajectory 
from  the  departure  airport  to  the  destination  airport  which 
meets  the  defined  constraints.  In  the  lateral  plane,  this 
trajectory  will  be  along  great  circle  arcs  between  waypoints 
and  will  follow  circular  arcs  of  defined  radii  when  turning 
from  one  leg  to  the  next  The  generation  of  altitude  and 
airspeed  profile  is  based  on  generic  profiles,  which  result  from 
the  application  of  the  initial  'Phase  Table’  together  with  initial 
conditions  (flight  stams,  aircraft  initial  weight  etc.).  The 
profile  will  be  modified  to  fit  within  the  constraints  by 
changing  altitude,  speed,  thrust  index  and  energy  sharing 
index  initially  defined  in  the  'Phase  Table'  in  an  appropriate 
manner. 

The  prediction  of  the  trajectory  comprises: 

-  generation  of  route  description  (2D-trajectory)  for  the 
given  set  of  waypoints  contained  in  the  constraint  list 

-  generation  of  altitude  (3D-trajectory)  and  airspeed  profile 
according  to  the  given  performance  parameters 

-  calculation  of  ground  speed,  range  and  flight  time  (4D- 
trajectory)  taking  wind  into  account 

-  modification  of  4D-trajectory  to  meet  all  constraints 

The  prediction  of  the  horizontal  path  makes  use  of  vector 
algebra.  The  prediction  of  the  airspeed  and  altitude  profiles  is 
based  on  the  integration  of  the  equations  of  motion,  which 
employ  models  describing 

-  lift  and  drag  of  the  aircraft, 

-  net  engine  thrust  and  fuel  flow  rale, 

-  properties  of  the  standard  atmosphere. 

The  strategy  of  how  to  predict  the  complete  trajectory, 
including  several  measures  to  modify  the  trajectory  such  that 
all  constraints  are  met,  is  described  in  the  following  chapters. 

4.1  Prediction  of  Horizontal  Route 
The  horizontal  route  between  departure  airport  or  present 
position  and  final  constraint  point  consists  of  great  circle  arc 
segments  and  circular  turn  segments  at  certain  waypoints.  An 
intercept  path,  a  holding  pattern  or  a  stretched  fan  path  may 
be  included,  as  is  shown  in  Figure  3.  Three  different  types  of 
waypoints  are  foreseen  to  comply  with  complicated  route 
structures: 
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Type  1:  Regular  waypoints,  which  describe  the  route 
without  the  turns  when  directly  connected 

Type  2:  Centre  of  Turn  points,  which  could  be  used  to 
construct  more  complicated  approach  paths 
including  turns  for  more  than  180  degrees 

Type  3:  End  of  Turn  or  Start  of  Turn  points,  which  allow 
to  predict  an  intercept  path,  a  fan  path  or  a  holding 
pattern 

The  prediction  starts  at  the  first  waypoint  of  the  route 
(departure  airport  or  present  position)  and  runs  to  the  last 
waypoint  of  the  route  (destination  airport  or  designated  final 
waypoint). 

4.2  Prediction  of  Vertical  Profile 

The  prediction  of  the  vertical  profile  comprises  up  to  three 
major  phases:  climb,  cruise  and  descent,  which  are  each 
composed  of  several  subphases  as  shown  in  Figure  4. 
Depending  on  the  present  status  of  the  aircraft  (on  ground  or 
airborne)  the  planning  strategy  is  selected.  This  defmes  the 
start  of  the  predicted  trajectory  as  either  the  take  off  point  on 
the  departure  runway  or  as  the  present  position  in  flight. 

If  the  aircraft  is  still  on  the  ground  the  prediction  of  the 
trajectory  starts  with  a  climb  phase,  proceeds  with  a  descent 
phase  and  finally  fits  in  the  cruise  phase.  If  the  aircraft  is 
already  flying  the  prediction  of  the  trajectory  starts  with  a  40 
seconds  straight  and  level  flight  segment.  From  there  follows 
a  climb,  cruise  or  descent  segment  depending  on  the  present 
state  of  the  aircraft,  the  length  of  the  route  and  other 
parameters. 

Altitude  and  airspeed  profile  are  predicted  by  integration  of 
the  equations  of  motion  for  each  subphase  according  to  thrust 
mode,  thrust  index  as  well  as  subphase  target  values  for 
altitude,  airspeed  and  energy  sharing  index  as  described  in  the 
'Phase  Table’  (see  Figure  5). 

The  predicted  flight  time  along  the  trajectory  is  received  from 
integration  of  time  and  ground  speed  (on  great  circle  straight 
segments)  or  turn  rate  (on  constant  radius  turn  segments) 
respectively  until  reaching  a  certain  trajectory  point  (e.g.  start 
of  subphase,  start  of  turn,  middle  of  turn,  end  of  turn  etc.)  on 
the  trajectory. 

The  climb  phase  and  the  cruise  acceleration  phase  are 
predicted  employing  a  commanded  thrust  index  setting.  The 
fust  subphase  is  flown  at  take  off  thrust  and  constant  speed 
CAS_CL0  until  reaching  the  thrust  reduction  altitude,  where 
the  thrust  is  reduced  to  maximum  continuous  thrust.  The  third 
climb  subphase  is  performed  as  an  energy  sharing  climb, 
where  the  energy  sharing  index  defines  the  proportion  between 
climbing  and  accelerating.  The  following  climb  subphases  are 
performed  either  at  constant  speed  (CAS_CL1,  CAS_CL2, 
MACH_CL)  or  at  constant  altitude  (FL100)  to  accelerate  the 
aircraft  from  CAS_CL1  to  CAS_CL2.  This  part  of  the  profile 
prediction  is  always  performed  by  forward  integration  until 
reaching  cither  the  Top  of  Climb  (TOC)  or  the  Cruise 
Acceleration  Point  (CAP)  at  cruise  altitude  ALT_CR,  as 
shown  in  Figure  4. 

At  this  point  the  final  weight  is  estimated  from  the  predicted 
aircraft  weight  and  then  used  for  the  subsequent  prediction  of 


the  descent  profile. 

The  whole  descent  phase  and  the  deceleration  subphase  at 
cruise  altitude  are  predicted  by  backward  integration  of  the 
equations  of  morion  for  each  subphase  according  to  the  thrust 
index  and  subphase  target  values  for  altitude,  airspeed  and 
energy  sharing  index  stored  in  the  'Phase  Table*.  The 
prediction  of  the  descent  profile  starts  at  the  Gate  taking 
altitude  ALT_GT,  speed  CAS_GT  and  estimated  landing 
weight  as  initial  values  and  runs  until  the  Cruise  Deceleration 
Point  (CDP)  is  reached. 

The  descent  profile  provides  two  level  segments,  one  before 
reaching  the  Gate  and  a  second  at  an  intermediate  altitude, 
e.g.  FL100  or  assigned  altitude  at  the  Metering  Fix  to  provide 
some  margin  for  the  possible  shift  of  the  position  of  the  end 
point  of  the  idle  descent  and  deceleration  subphr™.  major 
portions  of  the  descent  are  performed  at  constant  speed 
(MACH.DE,  CAS.DEl,  CAS_DE2). 

Subsequently  the  cruise  phase  is  predicted  by  forward 
integration  of  the  equations  of  motion  starting  at  the  Top  of 
Climb  until  reaching  the  Cruise  Deceleration  Point,  which  was 
found  in  the  course  of  the  prediction  of  the  descent  profile. 

The  aircraft  weights  at  CDP  received  from  forward  cruise 
prediction  and  backward  descent  prediction  are  utilised  to 
revise  the  estimated  final  weight.  Depending  on  the  difference 
in  final  weights  the  prediction  of  the  descent  and  cruise  profile 
may  be  repeated. 

4  J  Strategies  to  meet  Constraints 

Constraints  are  one  of  the  major  inputs  to  trajectoty 
prediction.  Constraints  are  windows  in  space  and  time  through 
which  the  aircraft  must  fly.  A  constraint  consists  of  a 
waypoint,  together  with  a  constraint  type,  describing  the 
nature  of  the  constraint  such  as  turning  point,  height  constraint 
point,  speed  constraint  point  or  time  constraint  point  A 
constraint  will  also  have  attributes,  detailing  the  actual 
limitations  being  placed  upon  the  aircraft  at  that  constraint 
e.g.  size  of  airspace  allocated  or  rime  slot  that  the  aircraft 
must  meet. 

The  development  of  strategies  for  the  prediction  of 
trajectories,  which  comply  with  multiple  4D  constraints  is  a 
major  research  issue.  Many  parameters  and  several  criteria 
have  to  be  considered,  such  as 

-  time  accuracy  of  predicted  trajectoty, 

•  efficiency  of  predicted  trajectoty  as  regards  fuel  consumption 

-  smoothness  of  thrust  control, 

-  acceptance  by  pilots, 

-  computation  time, 

-  number  of  iterations  needed 

to  mention  only  a  few.  The  following  chapters  describe  tome 
initial  solutions  of  how  to  comply  with  horizontal,  airspeed, 
altitude  and  time  constraints.  These  will  be  implemented  in 
the  Phase  1  version  of  the  EFMS  after  finalisation  of  the  still 
ongoing  prototyping  and  development  work. 

4.3.1  Horizontal  Constraints 

Horizontal  constraints  are  described  by  the  position  of 
waypoints  contained  in  the  constraint  list  with  additional 
attributes  describing  the  size  of  the  lateral  window.  At  lateral 
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turning  points  the  constraint  data  may  include  turn  radius  data. 
To  allow  path  stretching  to  be  applied  as  a  means  for  time  of 
arrival  control  in  the  TMA  there  are  several  waypoints 
provided  with  special  attributes  defining  the  path  stretching 
area. 

Horizontal  constraints,  i.e.  position  of  waypoints,  turn  radii, 
are  fully  taken  into  account  during  the  generation  of  the  route 
description.  In  the  Phase  1  version  of  the  EFMS  the  route  will 
follow  great  circle  arcs  between  waypoints.  The  lateral  size  of 
the  constraint  window  is  therefore  not  used,  i.e.  comer  cutting 
will  not  be  applied. 

4.3.2  CAS  Constraints 

Airspeed  is  mainly  restricted  by  the  allowed  speed  envelope  of 
the  respective  aircraft.  Besides  this  there  are  only  a  few 
additional  CAS  constraints  steming  from  ATC.  One  is  the 
CAS  restriction  to  250  kts  below  flight  level  FL100.  Another 
one  is  applied  at  the  Gate  waypoint  All  airspeed  constraints 
are  coped  with  by  inclusion  in  the  'Phase  Table',  which  is  the 
major  input  to  the  prediction  of  airspeed  and  altitude  profile, 
respectively. 

4J  J  Altitude  Constraints 

The  application  of  altitude  constraint  windows  at  waypoints  is 
defined  in  the  'User  Requirements  Document'  of  the  EFMS 
[2].  Figure  6  indicates  that  there  will  exist  an  upper 
(maximum)  altitude  constraint  and  a  lower  (minimum)  altitude 
constraint,  which  both  change  stepwise  depending  on  position. 
Both  may  prevent  the  aircraft  from  following  its  desired 
altitude  profile  as  defined  by  performance  parameters 
contained  in  the  'Phase  Table'. 

The  prediction  starts  utilising  the  nominal  performance 
parameters  from  the  initial  'Phase  Table’  thus  resulting  in  the 
pilot’s  desired  altitude  profile.  If  this  desired  profile  hits  a 
maximum  or  minimum  altitude  constraint,  then  measures  are 
taken  to  modify  the  subphases  of  the  profile  in  such  a  way, 
that  it  conforms  to  the  altitude  constraints. 

Different  measures  are  employed  depending  on  the  phase  of 
flight  and  the  type  of  altitude  constraints.  The  following  two 
examples  describe  how  altitude  constraints  affecting  the  climb 
at  constant  CAS  (or  Mach,  respectively)  are  handled. 

If  a  maximum  altitude  constraint  (see  Figure  7)  affects  a 
constant  CAS  climb  subphase  the  following  measures  are 
applied: 

Step  1:  A  constant  altitude  subphase  is  introduced,  which 
ends  when  the  altitude  constraint  is  raised  to  a 
higher  altitude. 

Depending  on  the  length  of  the  level  segment  is  decided,  if  it 
should  stay  in  or  if  it  should  be  substituted  by  a  climb 
subphase  comprising  a  smaller  climb  angie  to  avoid  major 
thrust  changes  within  a  short  time  span.  To  achieve  such  a 
smaller  climb  angle  there  exist  several  solutions,  such  as 

-  increasing  the  climb  airspeed, 

•  modification  of  Energy  Sharing  Index, 

-  reduction  of  thrust  index. 

The  latter  is  chosen,  because  it  allows  to  maintain  the  nominal 
airspeed  schedule. 


Step  2:  The  length  of  the  level  segment  is  cheeked  and  if  it 
is  shorter  than  4  Nautical  Miles  (Lb-d.),  the 
prediction  of  the  subphase  is  repeated  utilising  a 
lower  thrust  index  setting.  The  reduced  thrust  index 
is  received  by  a  simple  formula  derived  from  the 
force  equations. 

The  thrust  index  TH.ro  defined  for  the  EFMS  is  as 
follows: 

TH.ro  =  (THRUST  -  THRUST**)/ 

(THRUST**,  -  THRUST**) 

THRUST  actual  net  thrust 

THRUST**  minimum  achievable  net  thrust 

THRUST**,  maximum  achievable  net  thrust 

and  the  reduced  thrust  index  is  then 

THoro  red  “  THwo  -  W  *  (j^o*  -  Y,eq)/ 

(THRUST**,  -  THRUST**) 

W  aircraft  weight 

‘fc0M  nominal  flight  path  angle  from 

desired  climb  profile 

Yeeq  required  flight  path  angle 

If  a  minimum  altitude  constraint  (see  Figure  8)  affects  a 
constant  CAS/Mach  climb  subphase  the  only  measure  is  to 
climb  steeper.  This  could  be  achieved  by  either 

-  performing  the  climb  subphase  at  a  slower  airspeed,  or 

-  increasing  the  thrust  index. 

Since  the  thrust  index  is  supposed  to  be  set  at  100  %  during 
climb,  corresponding  to  maximum  continuous  climb  thrust,  it 
cannot  be  further  increased.  So,  the  solution  adopted  is  to 
reduce  the  climb  speed  accordingly. 

Step  1:  A  first  estimate  of  the  appropriate  climb  CAS  is 
derived  from  a  consideration  of  total  energy,  which 
exists  when  the  nominal  climb  segment  hits  the 
altitude  constraint  at  altitude  H,.  It  is  assumed,  that 
the  total  energy  available  at  that  time  could  be 
shared  in  such  a  way,  that  the  aircraft  passes  the 
altitude  constraint  at  altitude  H,.  This  yields  the 
improved  estimated  climb  speed  CASf 


CAS,  =  CAS_CL1  (or  CASJTL2) 


H,  nominal  altitude  of  flight  path  at  constraint 

H,  required  altitude  at  constraint 
VWJI  wind  speed  at  altitude 

g  gravity  of  earth 

p(  air  density  at  sea  level 

p„  air  density  at  altitude 

The  prediction  of  the  climb  subphase  is  repeated  and 
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yields  flight  path  angle  y,. 

Step  2:  The  flight  path  angles  received  for  the  subphase  of 
the  desired  climb  profile  and  for  the  modified 
subphase  are  compared  with  the  required  flight  path 
angle  necessary  to  pass  the  altitude  constraint. 
Linear  interpolation  is  applied  to  improve  the 
estimated  climb  speed. 

CAS,  —  CAS]  +  (CAS j  -  CAS|)*(Yr£q  *  Ynom)/ 

<Tj  -  TW>m) 

43.4  Time  Constraints 

Time  control  to  one  or  several  constraint  points  is  mainly 
important  at  the  end  of  the  route,  i.e.  during  the  final  portion 
of  the  cruise  flight,  the  descent  from  cruise  altitude  down  to  a 
Metering  Fix  and  the  final  flight  to  the  Merge  Gate  or  the 
runway  threshold.  4D  guidance  can  reduce  the  separation 
distance  between  aircraft  down  to  a  level  that  approaches  the 
minimum  separation  standards,  since  the  time  of  arrival 
deviation  at  various  constraint  points  can  be  greatly  reduced. 
This  reduction  in  arrival  dispersion  becomes  a  benchmark  for 
evaluating  the  performance  of  a  4D  system. 

There  are  two  basic  methods  of  time  control,  that  of  adjusting 
aircraft  speed  [3],  [4],  [S]  and  adjusting  path  length  [6],  (7]. 
The  choice  between  these  two  methods  is  driven  largely  by 
the  phase  of  flight  and  the  amount  of  time  adjustment  required 
(see  Figure  9).  The  most  economical  form  of  time  control  is 
airspeed  control  in  cruise  flight.  However,  in  later  phases  of 
flight  there  is  little  time  remaining  and  thus  the  amount  of 
time  control  possible  is  small.  The  extent  to  which  airspeed 
control  is  a  coarse  or  fine  tuning  device  is,  of  course,  a 
function  of  the  airspeed  range  of  the  aircraft. 

43.4.1  Speed  Control 

Time  control  in  the  cruise  phase  and  in  the  descent  from 
cruise  altitude  down  to  the  Metering  Fix  and  the  Gate  is 
achieved  by  altering  the  airspeed  (CAS)  within  the  allowed 
range  (Minimum  CAS,  Maximum  CAS)  when  predicting  the 
trajectory  between  constraint  points  A  and  B  (see  Figure  10). 
This  is  done  by  applying  a  search  strategy  comprising  three 
steps  providing  increasing  accuracy  in  the  estimated  airspeed 
values  and  arrival  times  at  the  respective  time  constraint  point, 
as  shown  in  Figure  11.  The  initial  prediction  of  the  trajectory 
is  performed  applying  the  nominal  airspeed  value,  i.e. 
CAS_CR,  CAS_DE1  or  CAS_DE2  respectively,  contained  in 
the  'Phase  Table',  thus  giving  the  arrival  time  at 

constraint  point  A  as  well  as  the  arrival  time  at  the  time 
constraint  point  B,  where  the  snivel  time  T9  ,  is  required. 

Step  1:  gives  a  rough  estimate  of  the  appropriate  airspeed 
value  to  be  used  for  the  first  iteration  of  the  profile 
prediction; 

CAS,  =  CAS_CR  (or  CAS.DE1,  CAS.DE2) 

CAS]  ■  CAS,  *  (T^y,  -  Tc.a)/(Tc  -  T(y  A) 

Application  of  CAS,  then  yields  the  arrival  time 
T®»>  which  is  used  to  derive  a  better  airspeed 
estimate. 


Step  2:  Linear  interpolation  is  applied  to  get  the  second 
estimate  of  the  airspeed  value  to  be  used  for  the 
second  iteration  of  the  profile  prediction: 

CAS,  =  CAS,  +  (CAS,  -  CAS,)*(T„  ,  -  T^,)/ 

(T®,  -  T„,) 

This  results  in  the  revised  arrival  time  TOT  at  the 
time  constraint  point,  which  in  turn  can  be  used  to 
improve  the  airspeed  estimate  once  more,  if  the 
required  time  accuracy  has  not  yet  been  reached. 

Step  3:  Quadratic  interpolation  is  used  to  further  improve 
the  accuracy  of  the  airspeed  estimate.  Firstly  the 
coefficients  (A,  B,  C)  of  the  interpolation  formula 
have  to  be  defined  utilising  three  pairs  of  data 
(CAS,,  To),  (CAS*  To).  (CAS,,  To)  and  &om 
this  the  speed  estimate  can  be  calculated: 

DT  =To.-Va 

CAS,  =  A  +  B  *  DT  +  C  *  DT* 

This  is  again  used  to  recalculate  the  trajectory 
resulting  in  the  arrival  time  To  at  die  time 
constraint. 

4343  Path  Stretching 

Time  control  in  the  TMA  can  also  be  achieved  by  altering  the 
length  of  the  flight  path.  Besides  the  Standard  Arrival  Routes 
(STAR)  with  a  fixed  route  pattern  there  will  exist  a  new  type 
of  STARs,  the  so-called  4D-STAR,  which  provides  a  path 
stretching  area  for  the  coarse  and  fine  tuning  of  arrival  rimes. 
The  path  stretching  area  will  allow  either  fan  type  or 
trombone  type  altering  of  the  flight  path  (see  Figure  9  and 
12). 

The  path  stretching  area  is  described  by  three  waypoints  with 
appropriate  attributes: 

Entry  Waypoint  WP,* 

The  Entry  Waypoint  is  part  of  the  4D-STAR  and 
defines  the  entry  into  the  path  stretching  area. 

Exit  Waypoint  WPn 

The  Exit  Waypoint  is  pan  of  the  4D-STAR.  It 
defines  together  with  the  Intercept  Waypoint  WP„ 
the  direction  in  which  the  aircraft  will  leave  the  path 
stretching  area. 

Intercept  Waypoint  WP„ 

The  Intercept  Waypoint  describes  where  the  aircraft 
has  to  turn  towards  the  path  stretching  Exit 
Waypoint  WPU.  Its  nominal  position  WPr,*™  is 
defined  by  the  4D-STAR. 

To  provide  for  time  of  arrival  control  the  position  of  the  End 
of  Turn  point  EOT,,  is  shifted  appropriately  along  the  straight 
line  segment  between  WP„  and  WPEX  within  a  specified 
range  around  its  nominal  position. 

In  the  Phase  2  version  of  the  EFMS  path  stretching  will  only 
be  applied  in  the  course  of  trajectory  regeneration  at  the 
Metering  Fix  or  when  the  aircraft  reaches  one  of  the  two 
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Update  Waypoint*  (WPw01  or  WPLTm). 

Update  Waypoint  WPLTB1  is  identical  to  the 
position  of  the  Stan  of  Turn  at  the  Entry  Waypoint 
WP«. 

Update  Waypoint  WPLTM  is  situated  about  40 
seconds  before  reaching  the  Start  of  Turn  SOTCT  at 
Intercept  Waypoint  WPq,. 

Path  regeneration  is  performed  iteratively  applying  a  search 
strategy  comprising  three  steps,  as  shown  in  Figure  13.  Curves 
A  and  B  in  Figure  13  describe  the  dependancy  between  arrival 
time  T  at  the  Gate  and  distance  D  between  Gate  and  End  of 
Turn  point  EOT,-,,.  Curve  A  corresponds  to  the  previously 
predicted  trajectory  yielding  arrival  time  T,  at  the  Gate, 
providing  an  accuracy,  which  has  been  regarded  sufficient, 
because  of  the  wider  time  horizon  of  that  previous  prediction. 
Since  the  aircraft  follows  the  4D-trajectory  only  within  certain 
tolerances,  curve  A  moves  sidewards  depending  on  observed 
error  in  arrival  time.  To  compensate  an  arrival  time  error  AT, 
as  shown  in  the  figure,  distance  D  has  to  be  modified  stepwise 
and  this  search  would  be  along  curve  B. 

The  search  starts  from  the  nominal  flight  path  in  the  path 
stretching  area,  which  is  understood  to  be  the  path  along  the 
published  4D-STAR  without  any  path  modifications.  From  this 
the  nominal  distance  D,  between  the  Exit  Waypoint  WP^  and 
(he  End  of  Tum  point  EOTg,  as  well  as  the  predicted  arrival 
time  at  the  Gate  T,  are  taken.  The  following  steps  are 
performed  to  predict  the  path  which  conforms  to  (he  required 
arrival  time  at  the  Gate  Tor- 

Step  1:  Depending  on  the  observed  arrival  time  error  AT  at 
the  update  point  the  position  of  the  End  of  Tum 
point  EOTcr  is  shifted  along  the  straight  segment 
between  WPq,  and  WPEX. 

D,  =  D,  +  AT  *  Vcs  -  AD/2 

^cs  ground  speed  on  the  straight  segment 
between  WPg,  and  WPEX 

AD  interpolation  interval,  e.g.  200  meters 

The  flight  path  between  the  update  point  and  the 
Gate  is  then  recalculated  to  give  the  arrival  time  T, 
at  the  Gate. 

Step  2:  The  position  of  the  final  End  of  Tum  point  EOTo,  is 
shifted  by  the  interpolation  interval  AD: 

Dj  —  D,  +  AD 

Flight  path  as  well  as  arrival  time  T,  at  the  Gate  are 
recalculated. 

Step  3:  The  estimated  position  of  the  End  of  Tum  point 
EOT9  for  the  time  accurate  path  is  then  produced 
by  linear  interpolation. 

D,  =  D,  +  AD‘(TOT  -  T,)/(T,  -  T,) 


4.4  Planning  Steps  for  a  Complete  4D-Trajectory 

The  prediction  of  a  complete  4D-trajectory,  which  conforms  to 
several  airspeed,  altitude  and  time  constraints  requires  certain 
subphases  of  the  vertical  profile  to  be  calculated  iteratively. 
This  iterative  process  consists  of  an  inner  loop,  which  aims  at 
meeting  horizontal,  airspeed  and  altitude  constraints  and  an 
outer  loop  to  cope  with  time  constraints.  The  example  shown 
in  Figure  14  comprises  16  planning  steps.  Arrow  heads 
indicate  forward  or  backward  prediction. 

The  generation  of  the  initial  trajectory  taking  horizontal, 
airspeed  and  altitude  constraints  into  account  consists  of 
planning  steps  1,  2,  3,  and  4. 

The  time  constraint  at  the  Cruise  Fix  CF  is  dealt  with  by 
iteratively  modifying  the  cruise  speed  CAS_CR,  as  described 
in  chapter  4.3.4.1,  comprising  planning  steps  5.  6  and  7. 

The  time  constraints  at  the  Gate  and  at  the  Metering  Fix  arc 
dealt  with  by  modification  of  descent  speed  CAS_DE1  and 
CAS_DE2,  respectively.  The  cruise  speed  applicable  for  the 
segment  between  Cruise  Fix  CF  and  Cruise  Deceleration  Point 
CDP  may  also  be  modified,  if  regarded  necessary.  This  pan  of 
the  planning  comprises  planning  steps  8,  9  and  10.  which  are 
then  iteratively  repeated  (steps  11,  12,  13,  and  steps  14,  IS, 
16). 

Regeneration  of  the  trajectory  in  flight  will  be  initiated 
depending  on  certain  events  or  when  the  aircraft  arrives  at 
predefined  update  points.  The  scheme  of  trajectory  prediction 
will  still  be  as  described  above,  but  it  will  start  at  present 
position  of  the  aircraft  and  the  prediction  of  subphases  already 
passed  will  be  left  out,  of  course.  The  criteria,  when  e.g.  to 
stop  the  iterative  search  for  an  appropriate  airspeed  for  time  of 
arrival  control  will  depend  on  flight  progress,  i.e.  time  horizon 
of  planning.  The  required  accuracy  of  the  predicted  40- 
trajectory  as  regards  arrival  lime  at  a  certain  time  constraint 
point  will  be  increased,  when  approaching  that  respective  time 
constraint  point,  thus  to  provide  a  symmetrical  margin  for 
likely  deviations  from  the  trajectory. 

5.  Conclusions 

This  paper  describes  briefly  the  functionality  of  an 
experimental  Flight  Management  System  (EFMS)  disetinct  for 
research  into  future  Air  Traffic  Management  concepts.  The 
development  of  this  EFMS  as  such,  is  a  major  research  and 
development  task.  Thus  it  was  decided  to  split  up  the 
development  of  the  EFMS  into  several  phases.  The 
development  of  a  Phase  1  version  of  the  EFMS  with  a  limited 
functionality  is  underway.  This  Phase  1  version  will  already 
be  applicable  for  initial  investigations  including  flight  trials 
with  experimental  aircraft.  The  strategy  for  the  prediction  of 
4D-trajectories  will  be  as  described  in  this  papier.  A  later 
version  of  the  EFMS  will  have  a  more  complete  functionality 
and  may  comprise  more  advanced  planning  strategies  to  be 
developed  in  the  course  of  the  planned  research  activities  with 
the  Phase  l  version  of  the  EFMS. 


The  time  accurate  path  to  the  Gate  can  then  be 
predicted  resulting  in  arrival  time  T,. 
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Figure  2.  Internal  Structure  of  the  EFMS  (Level  0) 
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Figure  9.  Measures  for  Time  of  Arrival  Control 
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Figure  13.  Strategy  to  Define  the  Stretched 
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Figure  14.  Strategy  for  the  Prediction  of  a  Complete  4D-Trajectory  which  Conforms 
to  Altitude  Constraints  and  Time  Constraints 
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SUMMARY 

A  computationally  efficient,  real-time  trajectory  optimization 
and  guidance  approach  for  hypersonic  aircraft  is  described. 
The  optimization  approach  is  based  on  Euler-Lagrange 
energy  state  approximations.  A  three-dimensional,  spherical- 
earth,  aircraft-motion  model  with  constraints  on  temperature, 
dynamic  pressure,  acceleration,  and  angle  of  attack  is 
employed.  Climb-to-orbit,  retum-from-orbit,  flight-to- 
designated-landing-site,  unpowered- abort,  and  powered-abort 
flight  conditions  are  considered.  Different  performance 
criterion  are  used  for  different  problems. 

Solution  methods  of  varying  computational  complexity  and 
performance  capability  are  developed.  An  exact  solution  to 
the  optimization  problem  using  iteration  on  adjoint  variables 
is  developed.  This  method  is  the  most  exact  but  is  not  suitable 
for  on-board  processing.  However,  it  serves  as  the  basis  of 
performance  comparison  for  the  approximate  methods. 
Approximate  solution  methods  suitable  for  onboard  guidance 
are  developed  for  the  climb-to-orbit  problem  and  the  flight-to- 
a- landing  site  problem. 

A  computationally  efficient  method  for  generating  footprints 
is  described.  Footprints  are  used  to  determine  when  to  start 
final  descent  and  to  identify  candidate  landing  sites  under  an 
air-breathing-engine  or  rocket-engine  abort  or  other 
emergency  conditions.  A  hypersonic-vehicle  guidance, 
navigation,  and  control  configuration  of  the  complete  optimal 
guidance  scheme  is  described.  Sensitivity  analysis  results  are 
included  for  climb-to-orbit  trajectories.  The  probability  of 
achieving  orbit  using  the  optimal  guidance  scheme  and  a 
stored  nominal  approach  are  compared. 

This  research  was  sponsored  by  the  Air  Force  Wright 
Laboratory. 

LIST  OF  SYMBOLS 
a  Speed  of  sound 

a^.  Normal  (altitude)  acceleration  command 

a^  Lateral  acceleration  command 

\  Cowl  area  of  air-breathing  engine 

C,  Capture  area  of  air-breathing  engine 

Cqq  Parasite  drag  coefficient 

CL  Coefficient  of  lift 

D  Drag 

E  Specific  energy 

Fz  Normal  forces 

^ia  Partial  derivative  of  the  normal  forces  with 
respect  to  angle  of  attack 
g  Gravity 


|  gravity  minus  orbital  relief  acceleration 
(g  -  V2/R) 

G  Performance  criteria 

h  Altitude 

1,^  Air-breather  specific  impulse 

Ijp^  Rocket  specific  impulse 

J  Performance  integral 

k  Induced  drag  coefficient 

L  Lift 

Mass  of  hydrogen 
ir^  Mast  of  oxygen 

M  Mach  number 

M,  Aerodynamic  moments 

My  Sum  of  pitching  moments 

Q  Dynamic  pressure 

R  Radius  from  the  center  of  the  earth  (R  *  R0+  h) 

Rq  Radius  of  the  earth 

S  Wing  reference  area 

T  Thrust 

t  Time 

u  Control  vector 

U),  Maas  flow  rate  of  hydrogen 

u0  Mass  flow  rate  of  oxygen 

V  Velocity 

x  State  vector 

z  Roll  control  variable  (z  =  tana) 

0  Longitude 

0  Latitude,  or  cross-range  position 

a  Angle  of  attack 

5  Elevator  deflection 

o  RoD  angle 

y  Flight  path  angle 

\  Adjoint 

p  Density 

n  Throttle 

y  Heading  angle  (East  =  0  deg) 

Subscripts 

a  Air-breathing  engine 

f  Final 

h  Hydrogen 

o  Oxygen 

r  Rocket  engine 

0  Initial 

INTRODUCTION 

A  key  element  of  optimizing  performance  and  operability  of 
hypersonic  aircraft  it  the  ability  to  generate  onboard  flight 
trajectories  that  optimize  energy  management  in  response  to 


mission  phase  demands  and  contingencies.  The  ability  to 
compute  these  trajectories  on  board  is  a  step  toward  providing 
the  autonomous  capability  required  for  hypersonic  vehicle 
operations.  Past  space  vehicle  programs,  such  as  Space 
Shuttle,  lacked  this  autonomy  and  consequently  required 
complex  ground  support  services.  A  truly  autonomous 
aerospace  vehicle  would  greatly  reduce  this  associated  cost 
by  providing  the  capability  to  accommodate  takeoff  delays, 
changing  mission  conditions,  low-fuel  conditions,  engine 
failures,  and  other  emergencies. 

The  objectives  of  the  hypersonic  aircraft  guidance  solution 
are  to  fly  from  a  given  latitude,  longitude,  altitude,  and 
velocity  to  a  specified  final  condition  while  minimizing  som  : 
performance  objective,  and  to  continuously  compute,  in¬ 
flight.  the  optimal  trajectories  between  the  changing  current 
vehicle  state  conditions  and  the  specified  final  state.  The 
optimization  problem,  then,  is  one  of  managing  kinetic, 
potential,  thermal,  and  chemical  energy.  For  onboard 
hypersonic  guidance  there  are  two  vehicle  optimization 
problems  to  be  considered:  climb-to-orbit  and  flight-to- 
landing-site.  Figure  1  depicts  both  problems. 


Climb  to  Orbit  Flight  to  Landing  8lta 

•  Final  condition*  •  Final  conditions 

Energy:  E  ,  Energy:  Ef 

Position:  None  Position:  6)  and  Sf 

Fuels:  mo2  0andmhz0  Fusls:  mhZ  0  and  m0  2  0 

•  Planar  problem  •  Three-dimansionol  problem 

•  Manage  fuels  to  reach  orbit  •  Predict  if  desired  landing 

with  uncertainties  sits  can  be  reached  with 

currant  fuel  condition* 

•  Guide  vehicle  to  selected 

caxni.u  landing  site 

Figure  1.  Hypersonic  Aircraft  Guidance  Optimization 

The  steps  in  the  development  approach  are  to: 

1.  Obtain  optimal  solutions  to  establish  the  upper  bound  of 
attainable  performance  and  establish  the  characteristics  of 
the  optimal  trajectories. 

2.  Assess  the  feasibility  of  using  optimization  for  onboard 
guidance. 

3.  Define  approximations  to  optimal  strategies  and  assess  the 
computational  requirements. 

4.  Select  the  best  approach  based  on  trade  between 
performance  and  processor  requirements. 

The  general  Euler-La grange  optimization  method  is  described 
below.  Then,  solutions  for  the  specific  problems  of  climb-to- 
orbit  and  flight-to-landing-site  are  presented.  Finally,  a 
complete  vehicle  in-flight  guidance  system  is  d  scribed.  The 


complete  onboard  system  combines  both  solution  approaches 
and  additional  features  such  as  real-time  footprints. 

GENERAL  EULER-LAGRANGE  OPTIMIZATION 
METHOD 

There  are  several  optimization  methods  available  for  solving 
optimal  guidance  problems.  Table  A-l  in  Appendix  A 
summarizes  some  of  these  methods.  The  solution  approach 
used  is  in  this  study  is  the  Euler-Lagrange  method.  Further 
details  on  the  problem  definition  and  solution  can  be  found  in 
reference  1. 

Solution  to  the  Optimization  Problem 

The  general  statement  of  the  optimization  problem  and  its 

solution  are  stated  below. 

Minimize  the  performance  integral,  J, 

■r 

J  =  Jo(x,u,t)dt 
a 

subject  to  these  constraints: 

x  =  f(x,u,t)  ;  xftg)  =  Xfl 
C(x,u,t)  <  0 

The  solution  to  this  optimization  problem  is  the  following  set 
of  Euler-Lagrange  equations. 

The  controls  are  found  by  minimizing  the  Hamiltonian: 

min(H). 

u 

The  Hamiltonian  is  given  by 
H  =  G  +  XTf 

The  adjoint  variables  X  are  given  by 


The  bound"  •  conditions  on  X  and  x  are  given  by  the 
transversality  conditions 

[  Hdt -  XTdx]  =0 

When  H  is  independent  of  time,  it  must  also  satisfy  the  fust 
integral  condition  H  =  0. 

The  hypertonic  aircraft  problem 

The  objectives  of  the  hypersonic  aircraft  guidance  problem 
are  to  fly  from  a  given  latitude,  longitude,  altitude,  and 
velocity  to  a  specified  final  condition  while  minimizing  some 
performance  objective,  and  to  continuously  compute,  in¬ 
flight,  the  optimal  trajectories  between  the  changing  current 
vehicle  state  conditions  and  the  specified  final  stale. 

Optimization  criteria 

Within  the  general  Euler-Lagrange  problem,  specific 
problems  for  hypersonic  vehicle'  may  have  different 
performance  criteria  and/or  different  specified  end  conditions, 
as  shown  in  Table  1. 

Vehicle  models 

The  vehicle  model  is  defined  by  the  equations  of  motion, 
engine  model,  aerodynamic  model  and  constraints.  The 
vehicle  configuration  is  defined  in  Figure  2. 
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Table  1.  Euler-Lagrange  Optimization  Criteria 
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R  =  R0+h 


V  cosy  siny 

- R - 

mh*'%,  +  “hr 

The  eight  stater  are:  velocity  (V),  flight  path  angle  (y), 
heading  (y),  altitude  f  longitude  (8),  latitude  (®),  mass  of 
hydrogen  (mi,),  and  mass  of  oxygen  (m^. 


’’he  flvr  control  variables  are:  angle  of  attack  (a),  elevator 
deflection  (S),  roll  angle  (a),  air-breathing  engine  throttle 
(n,),  and  rocket  engine  throttle  (nr). 


b.  Front  View 

Figure  2.  Vehicle  Configuration 

The  equations  of  motion  for  a  spherical,  rotating  earth  are  as 
follows: 

T  -  D 

V  »  —  g  siny  -mb?  r  cos®  (siny  cos® 

-  cosy  sin®  siny) 

(L-T.)cokj  ,  v2  ,  C0*T  * 

- (g-i-)-^  +  2o>oosyoos® 


The  general  form  of  the  force  and  moment  equations  are: 

L  =  QSCL(o.5.M) 

'  =  QSCD(o.6,M) 

T,  =  T  (x1,a,M,p,a) 

T,  =  T,(n,) 

M,  =  QSBCm  (a,5,M) 

Mt,  =  Mr,  (n,,a.Mrf.p.a) 

Mt,  =  Mjr  (it,) 

The  air-breathing  and  rocket  thrusts  in  the  body  axes  are 
expressed  as  follows: 

T,  =  I«p,  K,  *,  8  P  M  a  C, 

Tr  =  Tr,»»*r 

In  the  velocity  axes,  the  total  thrust  components  are: 

t,=t„+t„ 

Ts  =  kcTax+Trz  where  kj  S  0.3 

The  hydrogen  and  oxygen  fuel  flow  rates  are: 

T,  T,  8T, 

uh  =  T*  uo  =  j]1, 

‘»P»*  yl«Pr*  *‘«Pr* 

The  aerodynamic  drag  (D)  and  lift  (L)  functions  are 
expressed  as 

D  =  QS[Cdo  +  KaJ  +  K^S2] 
or 

D  »  QS[Cpo  +  KC2  ] 

L  =  QSCl  (M,a,6) 

The  total  pitching  moment  is  of  the  form 

My  »  QS^n,  +  T„z,  +  Tux,  +  Trar,  +  T„x, 

Constraint! 

The  constraints  on  the  trajectory  variables  may  be  of  the 
equality  or  inequality  type.  The  system  must  operate  in  such  a 
way  that  the  resulting  trajectory  does  not  violate  the 
constraints.  Some  typical  hypersonic  vehicle  constraints  are 
shown  in  Figure  3.  The  plot  (a)  shows  some  of  the  constraints 
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on  tn  altitude-velocity  grid.  Plot  (3b)  shows  the  throttle 
constraints.  The  flame-holding  constraint  prevents  the  fuel-to- 
air  ratio  from  becoming  so  small  that  the  engine  ceases 
operating.  The  other  throttle  constraint  is  an  active-cooling 
constraint.  Fuel  flow  must  be  retained  if  active  cooling  is 
employed. 


8 
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3 


Ram* 

Holding 


/^\  Active 
/  Cooling 


/- 


Mad)  Number 

b.  Minimum  Throttle 
Constraints 


*  Maximum  tuol-to- 
air  ratio 

■Maximum  angle ol 
attack 
■Maximum 
acoalaration 
■  Maximum  bank 
angle 


c.  Additional 
Constraints 


Figure  3.  Typical  Hypersonic  Vehicle  Constraints 


The  dynamic  pressure  is  limited  to  be  less  than  a  maximum 
value  and  greater  than  a  minimum  value  as  follows: 

SQnm 

The  temperature  due  to  aerodynamic  heating  is  constrained  to 
be  below  a  maximum  value  as  follows: 

TempsTemp^ 

where 

k2(Temp)4  =  k,Vp  V3  05C(a) 


Energy-State  Approximations 

To  reduce  the  difficulties  of  solving  the  two  point  boundary 
value  problem  resulting  from  the  full  Euler-Lagrange  solution 
equations,  an  approach  based  on  simplifying  approximations 
is  considered.  In  this  approach,  assumptions  and 
simplifications  are  made  to  reduce  the  number  and 
complexity  of  the  adjoint  variables. 

In  the  energy-state  approximations,  it  is  assumed  that  vertical 
motion  has  higher  frequency  dynamics  than  horizontal 
motion.  This  assumption  is  similar  to  the  assumption  that  the 
attitude  dynamics  are  at  a  higher  frequency  than  the 
positional  dynamics.  Ultimately,  both  assumptions  imply  that 
an  attitude  controller  and  a  vertical  motion  controller  are 
supplied  where  the  control  frequencies  of  the  successively 
higher  dynamics  are  separated  by  a  factor  of  10  or  more.  The 
y  and  h  differential  equation!  are  eliminated  and  replaced  by 
their  equilibrium  conditions.  The  energy-stile  equations  are: 


&-CT-P& 
y-At*no  -•j^-coayun* 

A  _  VC0*V 

9  V* 

^VsnV 


;  R-Rg  +  h 


mh  *  “h,  + 
mo  =  “ot 

The  energy-state  assumptions  result  in  vertical  force  and 
pitching  moment  equality  constraints: 

Fz  =  L-T12-Tra-mg  =  0 

My  =  QScCm  +  T„z,  +  T„xt  +  TfgZj.  +  T„x,  =  0 

Using  vertical  equilibrium,  the  maximum  acceleration  and 
stall  inequality  constraints  become: 

<°i  .  t 

jaLO—i.  <C|  ;  J2t-Sa„ 

OioV^S  Htu*  CO*  a  nmu 

With  the  energy-state  equations  of  motion,  the  Hamiltoaiian 
reduces  to: 


H-G  +  ^i^+^+VTx-D>£ 


+  v, 


i  v2 
—  tana  -  —  oosytxnt  +  X^-X^m. 


The  adjoint  equations  Xj,  and  Xy  have  been  eliminated.  The 
remaining  adjoint  equations  are: 

X9=0 

Further  Simplifications 

By  applying  the  energy-state  assumption,  the  number  of 
states  has  been  reduced  and  two  adjoint  equations  have  been 
eliminated.  The  Euler-Lagrange  energy-state  equations  can  be 
further  simplified  as  follows. 

Analytical  solution  to  adjoint  equation 
If  the  performance  criterion,  G,  does  not  explicitly  include  die 
ststes  0,  $  or  y,  it  is  possible  to  solve  the  Xg,  Xg,  and  Xg 
differential  adjoint  equations  in  closed  form.  The  solution  is 
derived  in  Vinh  (Reference  2).  From  Vinh,  the  solution  takes 
the  form: 

XgaC, 

Xg  =  CjsinO  -  C3cos0 

Xg  *  C,  sin6  +  (CjCOsO  +  C3sin0)cosy 

Reformulation  of  adjoint  constants  of  integration 
The  adjoint  constants  are  expressed  in  terms  of  three  other 
constants  that  have  physical  meaning.  From  Vinh,  the  adjoint 
constants  form  a  vector  that  is  perpendicular  to  the  final 
position  and  velocity  vector.  The  final  condition  on  Xg  (Xg  * 
0)  is  used  to  eliminate  one  parameter.  The  constant*  in  term* 
of  the  new  parameters  are: 


Ct  =  cosO(CosVfC0 

Cj  =  (sinOfsimpf  -  cos0fsin$fcos  vf)C0 
Cj  =  (-cot6f*inVf  -  *in0j*  in^jcosvf  )C0 

Vf  is  the  final  heading  angle  and  Cq  is  related  to  the  cruise 
minimum-fuel  flow  rate. 

Elimination  of  the  adjoint  constant  kg 

The  adjoint  constant  Ag  is  eliminated  using  the  minimum 

principle  and  the  first  integral  as  follows: 

H(u*)<  H(u*  +  Au)  ;  H  =0 

where  u*  is  the  optimal  control  and  u*  +  Au  is  the  non- 
optimal  control.  The  derivation,  which  is  presented  in 
Reference  3,  results  in  two  possible  operations  on  a  new 
Hamiltonian  Ha: 

"uf1  [H,(u)l  ;  if  E>0 
m5*[H.(u)]  ;  if  E  <0 
Selection  of  extremum  operation 

The  elimination  of  the  adjoint  variable  Ag  results  in  two 
possible  extremum  operations.  The  condition  for  switching 
between  extremum  operations  can  be  determined  using  the 
continuity  of  Ag  and  Ag  =  -min(Ha)  or  Ag  =  -max(Ha).  The 
switching  condition,  which  is  derived  in  Reference  3,  is 

max  (H,)^  =  min  (H,^ 

The  starting  operation  is  still  unknown  at  this  point. 

Finding  extrema  of  the  Hamiltonian 

The  optimal  controls  are  found  by  determining  the  extrema  of 

the  Hamiltonian  with  respect  to  the  controls: 

E«remum(Ha)^0  .  Extremum  =  {“£  J  f«® 
tta  rcr  ho  My  _o  ’ 

Summary  of  the  General  Energy-State  Solution  Method 
In  summary,  the  steps  in  the  solution  of  the  general 
hypersonic  guidance  problem  are  the  following. 

1.  Choose  starting  operation  (i.e.,  maximize  or  minimize 
Ha). 

2.  Pick  initial  values  of  adjoint  constants  (Vf.  Cq)  and  fuel 
adloinu  Kv  *mh' 

3.  Compute  minimum  of  Hamiltonian  with  respect  to 
controls  (ita,]tph,o). 

4.  Compute  angle  of  attack  and  elevator  from  vertical  and 
moment  equilibrium. 

3.  Increment  equations  of  motion  to  next  time  point 

6.  If  necessary,  switch  optimizing  operations  when  they  are 
equal. 

7.  Stop  integration  at  final  energy  Ef. 

8.  Compute  misses  on  final  conditions  (i.e.,  specified 
position,  fuel  masses,  adjoints). 

9.  Update  adjoints  using  final  misses. 

10.  Repeat  (from  3)  until  misses  are  small. 

In  the  next  two  sections,  the  solutions  to  specific  hypersonic 
optimization  problems  are  discussed.  We  will  see  that  many 


of  the  above  listed  steps  are  eliminated  for  certain  problems, 
such  as  minimum  fuel  climb-to-orbit.  Also,  many  of  the 
above  steps  can  be  accurately  approximated  using  state 
feedback  and  switching  logic. 

SOLUTION  FOR  CLIMB  TO  ORBIT 
The  solution  for  minimum-fuel  climb  to  orbit  is  developed. 
The  goal  is  to  reach  a  final  orbital  energy  using  the  minimum 
amount  of  fuel  without  violating  the  constraints.  First,  the 
exact  optimal  solution  is  derived,  and  then  approximate 
solution  methods  are  described.  Finally,  recommendations  for 
onboard  guidance  are  given  and  simulation  results  are 
presented. 

Exact  CUmb-to-Orblt  Energy  State  Solutions 

The  performance  integral  for  the  minimum-fuel  climb-to- 

orbit  problem  is 

•t 

J  =  J  ( +  % )  dt 

o 

where 

%  =  :  “o=">o 

The  terminal  conditions  define  the  exact  problem  to  be 
solved.  If  neither  final  fuel  mass  is  specified,  the  final  energy, 
Ef.  is  the  only  terminal  condition.  If,  however,  the  final  mass 
of  one  of  the  two  fuels  is  specified,  there  are  two  terminal 
conditions:  Ef  and  either  m|,(tf)  or  m0(tf).  We  refer  to  this 
problem  with  a  specified  final  fuel  mass  as  the  minimum 
fixed-fuel  problem. 

When  solving  for  climb-to-orbit  without  specifying  the  final 
orbital  inclination  or  right  ascending  node,  the  minimum  fuel 
problem  reduces  to  one  of  only  three  stales:  E,  mg.  and  m^. 
This  assumes  a  planar  climb  to  orbit.  This  is  not  an  unrealistic 
assumption  when  considering  that  a  plane  flying  to  orbit 
would  maneuver  itself  into  the  desired  orbital  plane  as  soon 
after  takeoff  as  safety  requirements  permit.  The  remainder  of 
the  flight,  approximately  Mach  0J  to  23,  would  be  mostly  in 
the  vertical  plane  with  no  significant  bank  angle.  This  allows 
us  to  ignore  the  position  states.  The  three  remaining  states 
are: 

E  =  cr,-D)* 
mti  =  “h,  ♦  utv 
mo  =  Uor 

Thus  for  climb  to  orbit,  the  energy-state  Hamiltonian  takes 
the  simplified  form.  Note  that  the  adjoints  act  as  weighting  on 
the  type  of  fuel  used: 

H  -  K+Uo  +  Xmt,“t.+Vn,,>lo 

*~L  <T.-D)£  J 

For  climb  to  orbit,  the  rate  of  change  of  energy  is  always 
greater  than  zero.  Thus,  the  optimal  controls  are  found  by 
determining  the  minimum  of  H,  with  respect  to  the  controls 
na,  n,,  and  h: 

min[Ha(na,nrh))§>o 

where  a  and  6  are  determined  by  the  vertical  force  and 
pitching  moment  equilibrium  equality  constraints. 


Thus,  (he  climb-to -orbit-solution  differential  equations  are: 


E=(T,-D)i 

=  Uht  +“hr 
m0  =  u„t 

"  D  +  (mh  +  mo  )cp  ] 
^0  =  Hi^^rj[Tx  -  D  +  (mh  +mo)Cp] 


iterating  on  the  initial  values  of  the  fuel  adjoint!  to  meet  the 
final  conditions.  The  solution's  steps  include  the  following. 

1 .  Pick  initial  values  of  fuel  adjoins  ^(ij  and  X^It^). 

2.  Search  for  minimum  of  Ht  with  respect  to  controls 
(n^Kph)  for  current  states. 

3.  Compute  a  end  6  from  vertical  and  moment  equilibrium. 

4.  Increment  motion  and  adjoint  differential  equations  to  next 
time  point 


where 


S.  Stop  integration  at  final  energy  Ef. 


Cp  = 


T,a-[D„  +  D5(|k)] 


-F„ 


p  p  M° 

vo  *«M^ 


The  initial  and  final  conditions  on  the  adjoints  ire  given  by 
the  transversal! ty  conditions: 


[Mmh  +  Mm0] 


‘f 

lo 


=  0 


The  values  of  the  adjoints  depend  on  the  specific  problem  to 
be  solved.  The  fixed-fuel  -problem  solution  minimizes  the  fuel 
used  to  reach  orbit  without  exceeding  specified  final  fuel 
masses. 

In  (his  problem  the  vehicle  has  been  designed  and  the  vehicle 
mass  and  the  fuel  masses  are  fixed.  The  initial  design  may  or 
may  not  have  been  obtained  with  Euler-Lagrange 
optimization  tools.  The  goal  is  to  minimize  the  fuel  used 
without  exceeding  the  specified  fuel  weights.  If  the  Euler- 
Lagrange  method  reduces  the  fuel  usage,  then  the  onboard 
fuel  safety  margins  can  be  increased.  A  similar  problem 
maximizes  the  final  energy  for  given  amounts  of  fuel. 


6.  Compute  misses  on  m^ftf)  =  nn,f  and  X^tf)  =  0. 

7.  Update  fuel  adjoint  guesses  using  final  misses. 

8.  Repeat  until  misses  approach  zero. 

The  iterative  process  is  straightforward  and  could  be 
automated  easily.  However,  a  3-0  search  on  Ha,  which  is 
computationally  intensive  is  required  to  find  the  controls;  die 
3-D  search  together  with  the  need  for  iteration  makes  this 
exact  solution  unlikely  as  a  candidate  for  onboard,  real-time 
guidance.  Therefore,  we  looked  at  approximations  to  the 
above  problem  that  eliminate  the  need  to  iterate  on  the 
adjoints  and  reduce  the  order  of  the  search  for  the  optimal 
controls. 

Approximate  Solution  Methods  for  the  Cllmb-to-Orblt 
Problem 

Following  is  a  discussion  of  approximate  solution  methods  to 
the  climb-to-orbit  two-point  boundary  value  problem. 

Method  for  approximating  the  fuel  adjoints 
The  exact  solution  to  the  two-point  boundary  value  problem 
requires  that  the  optimal  controls  are  used  to  forward- 
integrate  the  equations  of  motion  and  the  adjoints  axe  adjusted 
until  the  solution  converges. 


For  the  purpose  of  clarifying  the  discussion,  let  us  assume 
that  it  is  the  mass  of  hydrogen  that  is  fixed  at  the  final  time. 
Note  that  the  approach  is  identical  for  fixed  final  oxygen 
mass;  simply  replace  1%  with  m^,  and  vice  versa  below.  The 
minimum  fuel  optimization  problem  for  fixed  final-hydrogen 
mass  takes  the  form: 

minimize 
[Ha  (h,  rtj, 

Initial  Conditions: 


The  values  of  the  adjoints  act  as  weighting  on  the  fuel  type 
used.  To  decrease  hydrogen  usage,  the  hydrogen  fuel  adjoint 
must  be  increased.  The  additional  weighting  reducer  future 
hydrogen  use.  The  iterative  process  required  to  solve  for  the 
fuel  adjoints  can  be  automated  to  update  the  adjoints  using 
the  predicted  deficiency  or  excess  of  a  particular  fuel.  For 
example,  assume  that  during  die  low-speed  flight  regime,  (he 
air-breathing  engine  bums  more  hydrogen  than  expected.  To 
compensate  in  flight  for  this  deficiency  of  hydrogen,  we  can 
increase  the  hydrogen  adjoint,  as  follows: 


E(io)  »  Eo.  oifafto)  =  mho.  m0(t„)  =  m^ 

X^fto)  *  free,  Xmo(t0)  =  free 
Final  Conditions: 

E(tf)  -  Ef.  mh(tf)  =  mhf,  m^tf)  =  free 
Xmh(tf)  =  free,  X^tf)  =  0 

From  the  transvenality  equations  we  get  a  final  condition  on 
the  oxygen  fuel  adjoint.  If  a  state  is  not  fixed  at  the  final  time, 
then  the  corresponding  adjoint  must  go  to  zero  it  tf.  Thus,  we 
have  a  two-point  boundary  value  problem.  The  initial  i tales 
are  known,  and  the  two  initial  adjoint  values  are  unknown.  At 
the  final  time,  two  states  and  one  adjoint  are  known,  leaving 
one  state  and  one  fuel  adjoint  free. 

The  exact  solution  for  the  climb-to-orbit  problem  requires 


■radioed 


Similarly,  for  a  deficiency  of  oxygen,  the  adjoint  correction 
takes  the  form 


^m0  =  + 


predicted 

% 


where  mtfre<llcte<i5  the  final  miss  of  hydrogen  and 
^predicted1  ^  majj  0f  oxygen. 

Further  approximate  methods  can  be  used  to  eliminate  the 
need  to  directly  determine  the  adjoints.  Since  the  fuel  adjoints 
act  aa  weighting  on  the  type  of  fuel  used,  the  net  effect  of 
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changing  the  value  of  a  fuel  adjoint  is  to  change  the  point  at 
which  the  rocket  engine  comes  on.  For  example,  increasing 
the  hydrogen  fuel  adjoint  results  in  the  rocket  engine  coming 
on  earlier  than  in  the  nominal  case  so  that  more  oxygen  and 
less  hydrogen  are  burned.  A  simple  method  for 
approximating  the  fuel  adjoints  is  to  directly  compute  the 
energy  level  at  which  the  rocket  comes  on.  As  in  the  previous 
method,  the  energy  level  for  rocket  ignition  is  determined 
using  predicted  final  fuel  masses: 

E,-E,,k<dk“ 

When  using  this  method,  it  is  no  longer  necessary  to  perform 
the  search  for  the  rocket  throttle.  'Hie  rocket  comes  on  when 
the  vehicle  reaches  the  specific  energy  Er.  Thus,  wc  have 
reduced  the  3-D  search  for  the  optimal  controls  to  a  2-D 
search  on  altitude  and  air-breathing  throttle.  By  neglecting  the 
small  differences  in  A^  and  A^.  such  that  A^,.  «•  ATT,o,  the 
adjoints  can  be  factored  out  of  the  Hamiltonian.  Thus,  it  is  no 
longer  necessary  to  compute  and  integrate  the  fuel  adjoint 
differential  equations.  The  optimization  problem  now  has  the 
form 


min 

h.*. 


(Uh  +  Up) 

V'-Wl  . 


E>0 
*r  *  *r 


Approximate  methods  for  finding  the  minimum  of  the 
Hamiltonian 

The  exact  optimal  climb-lo-orbit  solution  requires  a  3-D 
search  of  the  Hamiltonian  to  find  the  optimal  controls  (x,,  x,, 
h)  for  the  current  time.  This  can  be  computationally  very 
demanding.  The  approximate  methods  in  Figure  4  for 
determining  the  optimal  controls  are  aimed  at  reducing 
processing  requirements. 
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•  3-D  search  on  altitude  and  throtltes 
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•  1-D  search  on  altitude  with  separate 
2-0  search  on  throttles  and  analytic 
bank  angle 

•  1-0  search  on  altitude  with  Mach 
scheduled  throttles  and  analytic 
bank  angle 

•  Stored  tables  lor  altitude  parameterized 
as  a  function  of  energy  and  range  to  go, 
analytic  descent  altitude,  Mach  scheduled 
throttles,  and  analytic  bank  angle 
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Figure  4.  Methods  for  Finding  the  Minimum  of  the 
Hamiltonian 


Either  the  second  or  third  approach  in  Figure  4  is 
recommended  as  the  onboard  guidance  scheme  for 
determining  the  controls  at  the  current  time.  Both  these 
schemes  closely  approximate  the  exact  optimal  solution,  and 
they  can  be  easily  implemented  for  real-time  guidance  with 
today's  processing  capabilities.  The  stored  table  approach  is 
proposed  for  fast-forward  solutions. 


Summary  of  Cllmb-to-Orblt  Guidance  Approach 
The  climb-lo-orbit  guidance  approach  is  summarized  in 
Figure  3.  The  fast-forward  solution  integrates  a  model  of  the 
equations  of  motion  ahead  in  time  to  predict  the  final  fuel 
masses.  The  controls  for  the  forward  integration  are 
determined  from  parameterized  tables.  The  predicted  final 
fuel  masses  are  considered  and  a  go/no  go  decision  is  made. 
The  final  fuel  masses  are  used  to  adjust  the  rocket  on  point, 
and  the  optimal  controls  (h  and  na)  for  the  current  state  are 
determined  from  two  1-D  searches  of  the  Hamiltonian. 

Figure  6  is  an  example  of  a  climb-to-orbit  trajectory  using 
this  guidance  approach.  In  this  example,  the  vehicle  starts 
with  nominal  fuel  conditions  at  Mach  3  with  enough  fuel  to 
reach  orbit  under  nominal  conditions.  But  between  Mach  3 
and  Mach  12,  the  vehicle  bums  7%  more  hydrogen  than 
anticipated.  Thus,  at  Mach  12,  the  vehicle  has  a  deficiency  of 
hydrogen.  Without  compensation,  the  vehicle  would  run  out 
of  hydrogen  at  a  velocity  of  20,700  ft/s.  Instead,  the  guidance 
algorithm  begins  forward-integrating  to  quantify  this 
deficiency.  The  prediction  is  used  to  change  the  rocket  turn¬ 
on  point.  This  predictor-corTector  scheme  is  repealed  until  the 
rocket  ignites.  Some  of  the  excess  oxygen  was  used  to 
compensate  for  the  loss  of  hydrogen,  and  the  vehicle  makes 
orbit  without  running  out  of  hydrogen.  The  plot  in  the  lower 
right  comer  of  Figure  S  shows  the  CPU  seconds  required  per 
5-sec  time  step.  The  spikes  indicate  when  forward 
integrations  were  performed.  We  see  that  the  fast-forward 
integration  takes  on  the  order  of  2  sec  of  CPU^  time  and, 
therefore,  is  performed  in  real  time  for  the  GHAME  vehicle 
model  (Reference  4)  used  in  the  simulation. 

Results  from  an  error  and  sensitivity  analysis  using  optimal 
guidance  for  climb-to-orbit  are  presented  in  Appendix  B. 

SOLUTION  FOR  FLIGHT -TO-LANDING-SITE 
The  solution  for  flight  to  specified  landing  site  is  described. 
Exact  and  approximate  solutions  are  developed.  The  goal  is  to 
start  at  a  given  latitude,  longitude,  and  energy  and  fly  to  a 
specified  latitude,  longitude  and  energy  while  satisfying  some 
performance  criterion.  This  problem  differs  from  the  climb- 
to-orbit  problem  in  that,  in  addition  to  the  fuel  masses  and 
energy,  the  position  states,  6  and  4.  are  also  specified  at  the 
final  time.  This  is  the  most  general  of  the  energy-state 
minimum-fuel  problems.  The  solutions  to  this  problem  are 
used  in  several  flight  modes  including  sub-orbital  flight  to  a 
specified  landing  site,  return  from  orbit,  and  powered  and 
unpowered  aborts. 

Exact  Energy-State  Solution  for  FI lght-to- Landing-Site 
The  general  energy-state  Euler- Lagrange  solution  for 
minimum-fuel  flight  to  landing  site  is  summarized  as  follows. 
The  performance  integral  I  is: 

'r 

J  =  J(u„  +  uo)dt 

o 

and  terminal  conditions  are: 

Ef  final  energy  final  masses 

6f  final  longitude  mj,(tf)  £  0 

<bf  final  latitude  m^lf)  £  0 


f  Ail  CPU  run  timet  lined  ate  the  results  of  simulations  performed  on 
>  Sun  3/60  computer  with  a  68020  processor  and  a  68881  floating 
point  co-processor. 
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Figure  S.  Summary  oi  Climb-to-Orbit  Guidance  Approach 


The  optimal  controls  are  found  by  determining  the  extrema  of 
the  Hamiltonian.  H,,  with  respect  to  the  controls,  u,  and 
subject  to  the  vertical  force  and  pitching  moment  equality 
constraints: 

u*  =  min  [Ht(h.  a.  it,.  it,)] 
u*  =  max  [H,(h.  o. rg]  <  Q 
subject  to 

Fv«x.6)  =  0 
My  (a,  6)  =  0 
C(x,u,t)  s  0 

The  Hamiltonian  has  the  form 

H*  =  [uh  +uc  +X0  + 

+xv  cos  V  tan  i. 

+  ^mhU),  +^m0uo]/[(T»x  +Trx  -D)-^-] 

One  extremum  operation  is  selected  at  the  start;  then  the 
extremum  operations  are  switched  when 

mK(H^<o  =  min(H»Wo 

The  adjoints  are  summed  up  as  follows: 

Xg*Ct 

Xy  m  C2»m0  -  Cjcos0 
Xy  ■  C  |  iin#  +  (CjCosO  +  C3sin6)cosp 
where 


C,=cos$jcosyA 

C2  =  (sinSfsinyf  -  cos0fSmtycosyf)Co 
C3  =  (-  cosOfsinyf  -  sinBfSin^fCosyf )C0 

The  constant  is  the  final  heading  angle  and  C0  is  related  to 
the  cruise  minimum-fuel  flow  rale  (Reference  2).  The  values 
of  the  two  adjoint  constants  are  unknown.  The  fuel  adjoint 
differential  equations  are  the  same  as  for  the  climb-to-orbit 
solution.  The  initial  values  of  the  fuel  adjoints  are  unknown 
and  the  final  values  depend  on  the  optimization  problem 
being  solved. 

In  summary,  the  steps  in  the  exact  iterative  solution  for  flight 
to  landing  site  are  as  follows. 

1.  Choose  starting  operation  (i.e.,  maximize  or  minimize 

H.). 

2.  Pick  initial  values  of  adjoint  constants  (yj,  CQ)  and  fuel 
adjoints  X^  and  X^. 

3.  Compute  minimum  of  Hamiltonian  with  respect  to 
controls  (7t,,nrh,a). 

4.  Compute  angle  of  attack  and  elevator  from  vertical  force 
and  moment  equilibrium. 

3.  Increment  equations  of  motion  and  adjoint  differential 
equations  to  next  time  point. 

6.  If  necessary,  switch  optimizing  operations  when  they  are 
equal. 

7.  Stop  integration  at  final  energy  Ef. 

8.  Compute  misses  on  final  conditions  (i.e.,  specified 
position,  fuel  masses,  adjoints). 

9.  Update  adjoints  using  final  misses. 

10.  Repeat  until  misses  sre  small. 


Takeoff  from 
Edwards  AFB 


altitude  -  velocity 


throttlea  lab. rocket! 
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In  the  iterative  solution,  Vf,  Co  ^mh.  and  Xm<j  are  selected  at 
the  start.  The  trajectory  is  then  integrated  to  the  end.  The 
solution,  however,  is  sensitive  to  Vf.  If  Vf  is  not  correctly 
chosen,  the  trajectory  diverges  near  the  end.  A  method  to 
reduce  this  sensitivity  is: 

if 

lyo'n'Vt-'O1 

then 

0  =  0 

Approximate  Solution  Methods  for  Flight  to  Landing  Site 
The  following  sections  discuss  various  approximations  for 
solving  the  Euler-Lagrange  two-point  boundary  value 
problem  resulting  from  the  exact  optimal  solution. 
Simplifications  are  made  for  the  adjoint  determination,  the 
climb/descent  switching  logic,  and  the  minimization  of  the 
Hamiltonian. 

Approximations  to  the  adjoint* 

Simple  approximate  solutions  can  be  obtained  for  the 
position,  heading  and  fuel  adjoints.  Adjoint  constants  Co  and 
Vf  can  be  approximated  as  feedback  functions  of  range  to  go 
and  heading  error,  respectively.  The  fuel  adjoints  can  be 
approximated,  as  in  the  climb-to-orbit  problem,  as  functions 
of  the  predicted  final  fuel  masses  where  the  final  fuel  masses 
are  determined  by  fast  forward  integration. 

Climb! descent  switching  approximation 
Logic  to  select  the  starting  operation  (maximizing  or 
minimizing  Ha)  can  be  approximated  using  relative  geometry 
of  the  desired  endpoint  to  the  current  vehicle  position  and 
energy.  The  method  results  in  defining  three  flight  regimes: 
initial  descent,  climb,  and  final  descent.  The  three  regimes 
and  switching  lines  are  shown  in  Figure  7. 
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Figure  7.  Climb/Descent  Switching  Regions 

Approximate  methods  for  finding  extremum  of  die 
Hamiltonian 

The  exact  optimal  solution  requires  a  4-D  search  of  the 
Hamiltonian  to  find  the  current  optimal  controls  (h,  o,  nv  nr). 
Various  methods  are  available  to  simplify  this.  They  were 
presented  above  in  Figure  4.  During  two  of  the  flight  regimes, 
initial  descent  and  final  descent,  analytic  expressions  for  the 
controls  can  be  derived.  Thus,  searching  the  Hamiltonian  is 


required  only  during  climbing  flight. 

For  detailed  derivations  of  the  above  approximations  the 
reader  is  referred  to  references  1. 2, 3. 3,  and  6. 

The  vertical  dynamics  that  were  neglected  ji  the  energy-state 
solutions  are  accounted  for  in  the  onboard  system  by  a 
command  coupler.  The  command  coupler  controls  the  vehicle 
to  the  computed  optimal  altitude.  There  are  a  number  of 
possible  options  for  a  control  variable.  These  are  altitude, 
density,  dynamic  pressure,  and  axial  acceleration  (the  Space 
Shuttle  approach).  Density  and  dynamic  pressure  are  difficult 
to  measure.  Axial  acceleration  is  useful  during  no-power 
descents,  but  is  not  useful  for  powered  climbs.  Altitude  is 
chosen  because  it  is  directly  measurable  by  the  inertial 
navigation  system,  and  it  can  be  used  in  climb  and  descent. 

The  altitude  and  cross -range  control  laws  are: 

anc  =  (^5”L)co*®®i  +  Mh-hc) 

-i-k^h-hj) 
ayc  =  gtano 


where  a„c  and  ayC  are  nongravitalional  accelerations.  The 
altitude  differential  equation  with  the  controller  included  is: 


Summary  of  FUght-to-Landing-Slte  Guidance  Approach 
The  exact  optimal  solution  is  computationally  very  complex 
and,  therefore,  not  recommended  for  onboard 
implementation.  Several  approximate  methods  are  better 
suited  for  onboard  guidance.  The  stored  parametric  table 
approach  is  recommended  for  the  fast-forward  solutions, 
because  it  has  low  computation  requirements.  The  search 
solution  for  the  climb  controls  is  recommended  for  guidance 
because  it  is  flexible  to  changes  in  models  and  low  fuel  usage. 

The  flight-to-landing-site  processing  elements  are:  (1)  current 
optimal  control  processing,  and  (2)  fast-forward  solution  to 
compute  final  fuel  weights.  These  are  shown  in  Figure  8. 

The  current  "optimal  control  processing"  box  in  Fig.  8  is 
shown  in  detail  Figure  9.  The  controls  for  the  fast-forward 
solutions  are  computed  in  the  same  way  as  the  current 
optimal  controls,  except  during  climb  where  pre-stored 
parametric  tables  are  used. 


Predated 

'Fuel 

Masses 


Figure  8.  Flight-to-landing-site  Processing 
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Optimal 

Controls 


Figure  9.  Processing  for  Computation  of  Current  Optimal  Controls  for  Flight-to-Landing-Sita  Mode 


The  inputs  to  the  guidance  processing  are  the  desired  final 
state  of  energy,  latitude  and  longitude,  and  the  current  states 
of  mass  of  hydrogen,  mass  of  oxygen,  altitude,  velocity,  and 
heading.  The  relative  geometry  module  computes  the  range 
and  heading  angle  to  the  end  point. 

In  the  flight-to-landing-site  approximate  solution,  the 
trajectory  is  broken  into  climb/descent  regions,  as  was  shown 
in  Figure  7.  In  the  initial  and  final  descent  regions,  analytical 
methods  are  used  to  compute  the  optimal  controls.  In  the 
climb  region  simplified  search  methods  are  used  to  oompute 
the  optimal  controls. 

This  climb/descem  processing  logic  separates  the  flight  area 
into  three  regions:  initial  descent,  climb  region,  and  final 
descent  The  final  descent  circular  region  is  computed  Grom 
fast-forward  solution  for  the  maximum  range  glide  and  the 
minimum  range  glide.  The  switching  lines  are  computed  horn 
an  analytical  expression.  The  method  for  computing  the 
controls  depends  on  the  area  where  the  final  point  is  located 
relative  to  the  aircraft. 

If  the  final  point  is  inside  the  initial  descent  region,  an 
unpowered  minimum  drag  descent  is  commanded.  The  rocket 
throttle  is  set  to  zero,  and  the  air-breather  throttle  is  set  at  the 
minimum  flame-holding  condition.  The  altitude  profile  is 
defined  by  the  minimum  drag  path  with  approximate  vertical 
equilibrium,  and  the  roll  angle  is  computed  to  drive  the 
heading  error  to  zero. 

If  the  aircraft  is  inside  the  climb  region,  a  powered  climb  is 
commanded.  The  current  optimal  controls  are  determined 
from  an  altitude,  air-breathing  throttle,  and  rocket  throttle 
search.  If  the  ratio  of  fuel  reaches  that  necessary  to  fuel  the 
rocket,  the  air  breather  is  turned  off.  The  roll  angle  is 
computed  to  drive  the  heading  angle  error  to  zero. 

At  the  time  when  the  final  point  is  selected,  it  is  not 
necessarily  known  if  there  is  sufficient  fuel  to  reach  that 
point,  especially  in  an  abort  situation.  Thus,  a  computation  is 
made  to  predict  if  the  desired  end  point  can  be  reached.  If  it 
can't  be  reached,  a  new  end  point  is  selected.  Different 
prediction  methods  are  used  depending  on  the  type  of  short 
Three  are  given  in  Table  3. 


For  no-power  and  rocket-power  configuration,  a  footprint 
(locus  of  point  that  can  be  reached)  can  be  computed. 
Because  of  the  simple  engine  models,  it  is  feasible  to  do  this. 
For  the  case  where  the  air  breather  only  or  the  air  breather 
and  the  rocket  are  operating,  it  is  computationally  difficult  to 
compute  footprints.  Thus,  for  these  cases,  only  a  single 
trajectory  to  the  selected  landing  site  is  computed.  The  fast- 
forward  computation  approach  is  shown  in  Figure  10. 


Table  3.  Prediction  Methods  for  Different  Failures 


Engines  Available 

Prediction  Method 

Air-breathing  Engine  only 
Rocket  engine  only 

Both  engines  operating 

No  engines  operating 

Fast  forward  solution  to  the  end 

Rocket  footprint 

Fast  forward  solution  id  the  end 

No  power  footprint 

This  trajectory  is  computed  with  the  same  algorithms  as  the 
current  optimal  solution,  except  for  the  climb  control 
solution,  which  is  simplified  to  reduce  computation  time. 
Stored  parametric  tables  for  the  air-breathing  throttle  and 
altitude  are  used.  A  model  of  the  vehicle  equations  of  motion 
is  used  in  the  solution. 

Figure  11  shows  simulation  results  for  a  three-phase 
descent/climb/descent  trajectory.  An  abort  was  triggered  at 
Mach  IS  during  a  climb  to  a  polar  orbit.  Following  die  abort, 
the  vehicle  turns  around  and  returns  to  Edwards  AFB. 


FOOTPRINT  GENERATION 

A  footprint  defines  an  area  of  attainable  final  points.  The 
Euler-Lagrange  formulation  of  the  footprint  problem  is  one  of 
maximizing  cross  range  for  a  series  of  specified  downranges 
as  follows: 


0 
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The  exact  optimal  solution  requires  iteration  on  one  adjoint 
constant.  For  onboard  real-time  implementation,  closed-form 
solutions  were  developed  that  closely  approximate  the 
optimal  controls.  The  details  of  the  solution  are  given  in 
reference  1.  The  unpowered  footprint  is  used  in  flight-to- 
landing-site  guidance  to  define  the  final  descent  region. 
Rocket-powered  footprints  are  used  to  determine  if  a  chosen 
landing  site  is  attainable  using  rocket  power  only  with  the 
current  fuel  masses. 

The  onboard  footprint  calculator  is  accurate  for  spherical 
earth  and  includes  earth's  rotation  effect  and  complex 
constraints.  The  method  for  calculating  a  footprint  is  shown 
in  Figure  12. 

The  footprint  is  calculated  starting  with  the  vehicle's  initial 
altitude,  velocity,  heading,  fuel  mass,  and  position.  The 
energy-state  equations  of  motion  are  integrated  along  the 
commanded  roll  angle  and  drag  profile  until  a  minimum 
energy  is  reached.  A  variable  time  step  depending  on  the 
magnitude  of  the  bank-angle  turn  rate  is  used.  At  the 
minimum  energy  point,  the  final  latitude  and  longitude  define 
the  footprint  boundary.  A  540-deg  sweep  of  heading  angles  is 
conducted  using  minimum  and  maximum  drag  flight 
conditions.  The  roll  angle  control  is  proportional  to  the 
heading  error.  The  trajectory  termination  points,  SO  in  all, 
create  the  closed  boundary.  The  CPU  time  to  create  an 
unpowered  footprint  is  approximately  5  to  10  sec  depending 
on  initial  Mach  number. 

For  powered  footprints,  it  is  desirable  to  fly  the  vehicle  at 
minimum  thrust  when  turning  at  high  rates  in  order  to  lower 
the  kinetic  energy  and  thereby  reduce  the  radius  of  curvature. 
The  switching  logic  is  similar  to  that  developed  for  the  flighl- 
to-landing-site  solution.  This  concept  is  illustrated  in  the 
diagrams  in  Figure  13. 

Figure  13a  shows  the  three  phases  of  'he  rocket-only 
trajectory  as  energy  losses  and  gains  and  the  distance  traveled 
in  each  phase.  In  the  initial  descent,  the  vehicle  is  turning  at  a 
high  rue  in  order  to  align  itself  with  the  commanded  heading. 
Once  the  vehicle  heading  nears  this  desired  heading,  the 
engine  is  switched  on  and  the  vehicle  climbs  until  all  of  the 
rocket  fuel  is  used,  at  which  point  a  glide  descent  begins. 
Figure  13b  shows  the  geometry  involved. 

The  footprint  for  unpowered  and  rocket-powered  flight  is 
shown  superimposed  over  a  world  map  in  Figure  14. 


IN-FLIGHT  VEHICLE  GUIDANCE  CONFIGURATION 
An  in-flight  guidance,  navigation  and  control  structure 
derived  from  the  optimization  solution  is  shown  in  Figure  13. 
The  system  configuration  combines  the  element  of  footprint 
generation,  fast-forward  prediction,  and  current  control 
processing  into  a  complete  vehicle  guidance  configuration. 

The  inputs  to  the  guidance  system  are:  the  type  of  mode  arid 
desired  final  conditions  from  the  pilot;  inertial  navigation 
sensor  position,  velocity,  and  heading  from  the  inertial 
sensors;  and  fuel  flow  rates  and  fuel  weight  from  the  fuel 
sensors.  The  processing  functions  are  optimal  guidance 
commands,  fast-forward  prediction,  footprint  calculation,  and 
an  altitude  command  coupler. 

A  fast-forward  prediction  module  computes  a  trajectory  with 
the  air-breathing  engine  operating  to  the  final  point  to 
determine  if  there  is  sufficient  fuel  to  reach  the  point.  The 
footprint  generator  finds  the  area  of  attainable  final  points  for 
unpowered  and  rocket-only  flight. 

The  optimal  guidance  command  module  computes  the  current 
optimal  air-breathing  throttle,  rocket  throttle,  altitude,  and  roll 
angle  commands.  These  are  output  to  the  command  coupler 
and  the  engine  controllers. 

The  optimal  acceleration  and  roll  angles  commands  are  sent 
to  an  attitude  controller. 

CONCLUSIONS 

The  Euler-Lagrange  energy-state  method  is  shown  to  be  a 
powerful  tool  in  solving  the  in-flight  vehicle  guidance 
optimization  problem.  For  in-flight  guidance,  the  Euler- 
Lagrange  energy-state  optimization  techniques  have  been 
extended  to  the  hypersonic  regime  and  3-D  turning  flight. 

The  approximate  approaches  give  trajectories  very  close  to 
the  full  optimal  solutions  for  minimum  fuel.  However,  the 
computing  time  is  much  lower  than  for  the  full  optimal 
iterative  solutions.  Thus,  the  approximate  Euler-Lagrange 
optimization  method  can  be  used  on-board  for  mission 
guidance.  This  approach  provides  for  high  flexibility  to 
mission  changes,  less  operator  involvement,  and  less  launch- 
site  support  for  pre-mission  trajectory  generation. 
Approximate  solution  methods  were  developed  for  the  climb- 
to -orbit  problem  and  die  flight-to-landing-site  problem. 
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Footprint  Calculation  Mat  hod 

•  Input  velocity,  altitude,  mass  of  fuel,  heading,  and  position 

*  Iterate  heading  command,  Vcgn, 

•an  (p)  » (H'com-  V)2 

5-^  »-£l 

*  Set  drag  to  min  or  max 

*  Variable  time  steo  tor  integration  ol  equations  ol  motion 

•  Stop  integration  when  minimum  energy  is  reached 

•  Footprint  boundary  defined  by  SO  points  ^ 

Figure  12.  Footprint  Generation  Method 


a.  Three-Phase  Footprint  Trajectory  Profile 


b.  Switching  Line  Geometry 


Figure  13.  Three-Phase  Powered  Footprint 
Trajectory  Diagrams 

In  the  climb-to-orbit  solution,  fast-forward  integration  is  used 
to  predict  final  hydrogen  and  oxygen  masses.  The  fuel  masses 
are  used  to  provide  information  for  a  go/no-go  decision  and 
for  control  optimization.  The  optimal  guidance  adjusts  the 
trajectory  to  account  for  fuel  mass  changes  due  to  vehicle 
uncertainties.  The  optimal  controls  are  determined  from  a 
simplified  search  method. 

An  enor  and  sensitivity  analysis  for  the  climb-to-orbit 
problem  shows  that  the  optimal  control  results  in  more  fuel 


margin  because  the  trajectory  is  adjusted  using  the  predicted 
hydrogen  or  oxygen  mass  (e.g..  if  the  hydrogen  fuel  is 
projected  to  be  low,  the  rocket  is  turned  on  sooner  so  that  less 
hydrogen  and  more  oxygen  is  burned,  so  that  all  of  the 
available  fuel  is  burned,  whereas  for  the  stored  profile  case 
the  mission  is  aborted  if  either  fuel  type  is  predicted  to  be 
exhausted).  Thus,  it  is  important  in  the  early  vehicle  design 
studies  to  include  trajectory  optimization  and  guidance 
analysis  because  the  ability  of  the  guidance  system  to 
accommodate  for  uncertainties  greatly  affects  the  magnitude 
of  the  fuel  margins  required. 

In  the  flight-to-landing-site  approximate  solution,  the  flight  is 
broken  into  climb  and  descent  regions.  In  the  descent  regions, 
analytical  methods  are  used  to  compute  the  optimal  control. 
In  the  climb  region,  simplified  search  methods  are  used  to 
compute  the  optimal  controls.  Fast-forward  integration  to  a 
landing  site  or  footprint  calculations  are  used  to  answer  the 
important  question  of  whether  there  is  sufficient  fuel  to  fly  to 
the  selected  landing  site.  The  fast-forward  solution  method 
determines  the  climb  controls  from  a  pre-stored  parametric 
table  of  the  controls  as  functions  of  range  and  Mach  number. 
In  the  event  of  mission  abort  with  the  air-breathing  engine 
still  operating,  the  flight-to-landing-site  solution  is  modified 
depending  on  the  type  of  configuration  available. 

A  computationally  efficient  method  for  generating  rocket- 
powered  and  unpowered  descent  footprints  is  also  described. 
Footprints  are  used  in  defining  the  three  flight  regimes  under 
normal  flight  conditions.  Under  air-breathing  engine  failure 
or  other  emergency  conditions,  footprints  are  also  useful  for 
quickly  identifying  candidate  landing  sites. 
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Figure  15.  Guidance  Navigation  and  Control  Configuration 


APPENDIX  A— CANDIDATE  OPTIMIZATION 
METHODS 

The  candidate  optimization  solution  approaches  and  a  brief 
comparison  of  their  capabilities  are  shown  in  Table  A-l. 

The  nonlinear  programming  methods  are  suitable  for  off-line 
computation  but  at  the  present  time  are  too  complex  for 
onboard  implementation.  The  best  candidate  for  real-time 
hypersonic  vehicle  trajectory  optimization  is  the  Euler- 
Lagrange  reduced -or der-modek  method. 

APPENDIX  B  •  ERROR  AND  SENSITIVITY 
ANALYSIS  FOR  CLIMB  TO  ORBIT 
The  objective  is  to  determine  the  likelihood  of  the  vehicle 
attaining  orbit  given  a  set  of  initial  conditions  and 
uncertainties.  A  Monte  Carlo  study  was  performed.  In  the 
Monte  Carlo  analysis,  perturbation  values  are  randomly 


selected  for  each  performance  parameter  based  on  chosen  lo 
values,  and  a  climb- to-orbit  trajectory  is  flown  using  these 
values.  The  Anal  velocity  achieved  for  this  configuration  of 
parameter  variations  is  recorded,  and  then  a  new  set  of 
random  perturbations  is  chosen  for  the  next  trajectory.  This  is 
repeated  until  sufficiently  many  trajectories  have  been 
generated  in  order  to  provide  a  good  idea  of  the  probability  of 
achieving  orbital  velocity.  In  this  study  500  trajectories  were 
generated  in  each  run. 

Table  B-l  shows  the  lo  values  used  in  this  study.  These 
selections  of  sigma  values  are  based  on  considerations  of  the 
models,  previous  studies,  GRAM  (Global  Reference 
Atmosphere  Model),  and  initial  results.  The  selections  are 
partly  arbitrary  and  are  certainly  not  meant  to  be  the  final 
word  concerning  the  lo  values. 


18-16 


Table  A-1 .  Candidate  Optimization  Solution  Approaches 


Approaches 

Comparison 

•  Euler- Lagrange 

•  Provides  general  solution 
but  results  in  two-point 
boundary  value  problem 
(TPBVP) 

-  Ne  wton-Raphson 

-  Reduced  order  models 

-  Singular  perturbations 

-  Has  sensitivity  problems 

-  Simplifies  the  TPBVP 

-  Gives  general  method  for 
model  reduction 

•  Gradient  methods 
-  Steepest  descent  methods 

•  Is  computationally  complex 
and  can  find  local 
minimums 

•  Nonlinear  programming 

-  Conjugate  gradient 

-  Feasible  directions 

-ons 

•  Can  solve  full  state 
optimization  problems  and 
handle  complex  constraints 
but  computationally 
complex 

Table  B-1.  1  a  Values 


Parameter 

lo  Error 

Drag 

±5% 

Specific  Impulse 

±6% 

Empty  Vehicle  Weight 

±5% 

Air  Density 

±7% 

Speed  of  Sound 

±4% 

Winds 

±30  ft/s 

Three  Monte  Carlo  runs  for  fuel  margins  of  0,  10,  and  20% 
for  both  the  pre-stored  and  the  optimal  trajectories  were 
completed.  The  final  velocity  distributions  for  each  run  were 
recorded  and  used  to  construct  the  probability  density 
functions. 

Figure  B-la  shows  the  probability  density  plot  for  the  pre¬ 
stored  algorithm  with  10%  fuel  margin.  It  compares  the 
number  of  occurrences  of  the  dimb-to-orbit  trajectory 
reaching  each  final  velocity.  Upon  inspection  we  see  that  the 
probability  of  the  trajectory  reaching  orbit  (-23,000  ft/s)  is 
slim.  This  plot  can  be  compared  with  the  probability  density 
results  of  the  optimal  algorithm  with  10%  fuel  margin  shown 
in  Figure  B-lb.  In  this  plot  a  much  more  favorable 
distribution  is  seen. 

Using  the  data  in  Figure  B-1  one  can  calculate  the  probability 
distributions  shown  in  Figures  B-2.  These  show  the 
percentage  likelihood  of  reaching  any  final  velocity  for  the 
different  algorithms  and  initial  fuel  margins.  For  instance,  in 
the  pre-stored  case  we  see  that  with  zero  safety  margin,  the 
dimb-to-orbit  has  approximately  a  4%  chance  of  reaching 
orbital  velocity,  while  the  optimal  guidance  trajectory  with 
zero  safety  margin  has  a  30%  dunce  of  reaching  orbit. 
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a.  Pro-stored  Trajectories  with  10%  Fuel  Margin 
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b.  Optimal  Trajectories  with  10%  Fuel  Margin 


Figure  B-1.  Probability  Density  of  Final  Velocities 


Final  VWody  (to) 

a.  Pre-stored  Trajectories 


Final  Votocar  (to) 


b.  Optimal  Trajectories 

Figure  B-2.  Probability  Distribution  of  Final  Velocities 

The  sensitivity  analysis  was  completed  using  the  GHAME 
vehicle  (reference  4).  The  value  of  using  optimal  trajectories 
has  been  demonstrated.  In  this  analysis,  if  the  nominal 
trajectory  contains  a  10%  safety  margin,  the  in-flight 
optimized  trajectory  has  a  70%  chance  of  reaching  orbit, 
while  die  pre-stored  trajectory  has  only  a  20%  chance. 
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1.  SUMMARY 

A  common  air  mission  planning  system  can  be 
designed  to  help  create  mission  plans  for 
various  aircraft  and  weapons  systems.  Even 
though  users  are  planning  missions  for 
different  aircraft,  they  perform  common 
functions,  access  identical  databases,  and 
operate  with  similar  procedures.  An 
architecture  based  on  modem  computer- 
communications  technology  and  widespread 
standards  can  exploit  this  commonality  to 
produce  a  mission  planning  system  of 
enduring  value.  (Ref.  1). 

The  USAF  Electronics  System  Division 
(ESD)  is  currently  developing  such  a  common 
air  mission  planner  in  a  phased  program  for 
multiple  aircraft  and  weapons.  It  is  called  Air 
Force  Mission  Support  System  (AFMSS)  and 
will  be  used  by  the  Strategic  Air  Command, 
Tactical  Air  Forces,  Military  Airlift  Command, 
and  Special  Operations  Forces  of  the  United 
States.  . 


This  paper  discusses  the  common  elements 
that  constitute  the  core  of  that  mission 
planning  system,  as  well  as  the 
accommodation  of  unique  elements  for  each 
different  aircraft.  The  open  system 
architecture  concept  is  established,  and  the 
technology  trends  and  standards  that  drive  that 
architecture  are  defined.  Performance  issues 
are  discussed,  and  the  Common  Mapping 
System  is  presented.  Finally,  future 
challenges  in  mission  planning  systems  are 
discussed. 

2.  ELEMENTS  OF  MISSION 
PLANNING 

In  generating  mission  plans  for  different 
aircraft,  many  of  the  functions  performed,  the 
data  accessed,  and  the  procedures  used  are 
quite  similar.  This  section  discusses  the 
common  elements  (listed  in  Table  1)  of 
mission  planning  systems  for  these  dissimilar 
aircraft 


Table  1 .  Common  Elements  of  Mission  Planning 


Common  Functions 

Common  Databases 

Common  Procedures 

Plight  Planting 

Route  Selection 
Ingress/Egress 

Take-off  and  Landing 

Threat  Penetration  Analysis 
Threat  Locations 

Terrain  Masking 

Aircraft  Visibility 

End-Game  Tactics 

Target  Visibility 

Weapon  Delivery 
Deconfliction 

Operational  Data 

Air  Tasking  Order 

Personnel 

NAVAIDS 

Weather 

Weapons  Data 
Communications  Plans 
MCG&I  Data 

Intel  Data 

Threat  Locations 

Imagery 

Electronic  Order  of  Battle 

Manipulate  Data,  Maps, 
Imagery 

Predict  Radar/IR/Visual 
Images 

Rehearse  Mission  (Fly  Thru) 
Initialize  Aircraft  Avionics 
Mission  Material  Preparation 

92-16181 

imiHiii 
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2.1  Common  Functions 

There  are  three  major  categories  of  functions 

that  are  performed  in  generating  a  mission 

plan: 

1 .  Flight  planning 

2.  Threat  penetration  analysis 

3.  End-game  tactics 

These  functions  are  common  to  all,  or  at  least 
certain  classes  of,  aircraft  and  weapons.  By 
determining  the  common  elements,  the 
software  architecture  can  be  constructed  to 
allow  re-use  of  these  elements,  thus  saving 
development  effort  and  time.  Right  planning 
encompasses  route  selection  for  ingress  and 
egress  as  well  as  calculation  of  parameters 
associated  with  take-off  and  landing, 
maneuvers,  and  fuel  consumption.  The  goal 
of  threat  penetration  analysis  is  to  determine  a 
path  of  minimum  danger  taking  into  account 
threat  locations,  terrain  masking,  and  aircraft 
visibility.  End-game  tactics  are  determined 
from  calculations  based  on  target  location  and 
visibility  and  on  weapons  parameters. 

Although  the  performance  parameters  are 
generally  different  for  each  different  aircraft 
and  weapon,  the  methods  of  calculation  are 
quite  similar.  For  example,  fuel  calculations 
for  different  aircraft  are  made  in  identical  ways 
using  corresponding  polynomials  or  look  up 
tables  that  describe  the  performance 
characteristics  of  the  different  aircraft.  Thus, 
it  is  possible  to  construct  common  software  to 
execute  the  common  functions  with  access  to 
separate  modules  containing  the  aircraft  and 
weapons-specific  parameters. 


2.2  Common  Databases 

There  are  also  three  common  classes  of  data 

that  are  needed  for  mission  plans  for  different 

aircraft: 

1 .  Operational  data 

2.  Mapping,  cartography,  geodesy  & 
imagery 

3.  Intelligence  data 

Thus  it  makes  sense  to  build  these  databases 
with  common  data  models  and  to  access  them 
with  common  protocols. 

Operational  (OPS)  databases  contain  mission 
information  obtained  from  both  higher  echelon 
commands  and  airbase  information  systems. 
For  example,  in  the  Gulf  War,  the  Theater 
Commander  issued  a  single  Air  Tasking  Order 
(ATO)  for  all  aircraft  in  the  theater  of 
operation.  Likewise,  weather  observations 
and  forecasts  are  common  to  all  aircraft  over 
the  target  area;  and  under  the  new  composite 
wing  concept  for  the  U.S.  Air  Force,  it  would 
be  reasonable  to  construct  a  single  common 
database  at  the  wing  to  supply  personnel, 
maintenance,  and  munitions  information  to 
mission  planners  for  dissimilar  aircraft. 
Mapping,  cartography,  geodesy  and  imagery 
(MCG&I)  databases  contain  maps  of  varying 
scale,  photographs,  terrain  elevation  and 
features  information.  A  list  of  the  types  of 
typical  MCG&I  products  for  mission  planning 
is  provided  in  Table  2.  Intelligence  (INTEL) 
databases  contain  threat  locations  and  target 
imagery  data,  which  have  to  be  registered  to 
the  maps.  The  inherent  size  of  these  databases 
is  quite  large,  and  they  utilize  a  large  portion 
of  storage  capacity  in  a  mission  planning 
system. 


Table  2.  MCG&I  Data  Types 


Arc  Digital  Raster  Graphics  (Scale  Varies) 

Digital  Terrain  Elevation  Data  (3  Arc-Second) 

Digital  Features  Analysis  Data  (3  Arc-Second) 

World  Vector  Shoreline  (1:250,006  scale) 

istrucaon  Data 
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By  standardizing  the  formats  and  methods  of 
accessing  these  databases,  theater-wide 
interoperability  is  ensured  between  Mission 
planning  systems  and  their  key  suppliers  of 
Command  and  Control  information.  In 
addition,  the  OPS,  INTEL,  and  MCG&I 
portions  of  the  mission  planning  system  can 
now  be  made  common. 

2.3  Common  Procedures 
All  mission  planners  have  the  need  to 
manipulate  and  display  data,  by  methods  that 
can  be  standardized.  Some  of  these 
procedures  include  manipulating  maps  and 
imagery  (panning,  zooming,  and  rapid  access 
of  different  types  of  MCG&I  data  for  the  same 
area  of  interest),  the  input  of  external  data  via 
autofeeds  and  physical  devices,  the 
compartmentalization  and  securing  of  data,  the 
presentation  of  visual  images  such  as  radar 
predictions  and  terrain  perspective  views, 
mission  rehearsal  (fly-through),  and  the 
creation  of  printed  materials  for  combat 
mission  folders. 

3.  OPEN  SYSTEM  ARCHITECTURE 

3.1  Development  Objectives 
The  development  objectives  for  a  common  air 
mission  planner  are  to  take  advantage  of 
common  functions,  databases  and  procedures 
and  to  provide  a  single  planner  for  a  variety  of 
aircraft  and  weapons.  This  single  planner, 
with  its  aircraft/weapon  specific  modules 
would  have  interoperability  through 
standardized  network  autofeeds  to  supply  the 
necessary  intelligence  and  operational  data  in 
real  time.  In  addition,  these  intelligence  and 
operational  data  feeds  need  to  interface  with 
only  one  mission  planner. 


The  goal  is  to  use  commercially  available 
products  whenever  possible.  For  example, 
high-end  workstations  are  deployable  to 
operational  airbases,  are  competitive  in  price, 
and  achieve  the  needed  performance.  By 
utilizing  commercial  standard  operating 
systems,  databases,  and  windows  packages, 
and  by  "re-using"  the  common  software  and 
developing  only  aircraft/weapon  specific 
modules,  overall  cost  for  providing  planning 
for  multiple  types  of  aircraft  and  weapons  is 
reduced.  To  continue  to  benefit  from  these 
advantages,  however,  the  software 
architecture  must  readily  allow  the  addition  of 
new  aircraft,  weapons  and  planning  functions 
in  a  way  which  decouples  the  software 
development  cycles  of  the  common  mission 
planner  on  one  hand  and  the  aircraft  specific 
software  and  avionics  software  on  the  other. 
In  addition,  the  planner  must  support  an  open 
system  architecture  which  allows  the  software 
to  be  easily  rehosted  to  new  hardware 
platforms  as  commercially  available  products 
change. 

3.2  Performance  Objectives 
The  performance  objectives  of  the  common  air 
mission  planner  are  to  permit  short  planning 
cycles  (as  low  as  15  minutes  for  some  fighter 
aircraft)  and  to  allow  threat  updates  of  large 
threat  databases  in  near  real  time.  Other 
performance  drivers  include  the  ability  to 
perform  radar  predictions  and  rapid  imagery 
manipulations,  such  as  terrain  perspective 
views  in  seconds  and  fly-through  at  rates  of 
one  to  five  frames/second.  Some  acceptable 
response  times  are  provided  in  Table  3  (Ref. 
2).  A  recent  study  (Ref.  3)  indicated  that 
response  times  of  under  0.5  seconds,  if  they 
can  be  achieved,  markedly  enhanced  operator 
productivity.  The  compression  and  display  of 
MCG&I  data  is  also  an  important  performance 
factor  in  evaluating  the  planner. 
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Table  3.  Mission  Planning  Display  Response  Times 


Function 

Response  Time 

2D  Displays 

Map  and  Plan  View  Displays: 

5.0  seconds 

Pan 

Zoom 

1.0  second 

Profile  Views 

5.0  seconds 

3D  Displays 

30  seconds 

Imagery 

Radar  Predictions 

10  seconds 

Electro-optical  Predictions 

10  seconds 

DFAD  and  VOD  Overlaid  on  DTED 

1.5  seconds 

Window  Interactions  (open,  close,  resize, 

1.0  second 

reposition,  select) 

Route  Fly-through  (movie  loop) 

1  to  5  frames  per  second 

This  performance  needs  to  be  provided  on  a 
worldwide  deployable  or  even  portable 
system.  It  is  to  be  used  by  the  aircrews  in  the 
field  and  therefore  should  be  user  interactive, 
and  user  friendly  with  rapid  response  rates. 

3.3  Elements  of  the  Architecture 
The  method  for  achieving  these  development 
and  performance  objectives  is  to  take 
advantage  of  the  latest  computer  technology, 
including  high-end  performance  graphics 
workstations  and  peripherals  packaged  in 
transit  cases.  A  distributed  client/server 
hybrid  architecture  allows  flexibility  and  cost- 
effective  use  of  peripherals  and  storage.  A 
combination  of  POSIX  compliant  secure 
operating  systems  and  commercially  available 
secure  databases  running  on  a  workstation 
provide  the  basis  for  a  multilevel  secure 
design,  that  protects  data  from  unauthorized 
access,  which  can  be  certified  as  required  by 
specific  users. 

Critical  for  making  the  system  adaptable  to 
new  weapon  and  aircraft  systems  is  the 
software  architecture.  This  needs  to  maximize 
the  use  of  common  re-usable  software 
modules  and  have  a  common  interface  to 
aircraft-unique  modules  of  objects,  that 
provides  isolation,  as  shown  in  figure  la. 
Without  such  an  architecture  the  "common"  air 
planner  would,  in  fact,  quickly  become  a 
collection  of  aircraft  specific  systems  with 
diverging  baselines  running  on  the  same 
hardware  suite.  This  common  software 


architecture  is  under  development  as  part  of 
the  AFMSS  contract,  and  MITRE  is  in  the 
process  of  developing  criteria  for  evaluating 
the  proposed  software  architectures.  Figure 
lb  shows  the  hardware  configuration. 

To  enhance  portability  and  interoperability,  a 
set  of  standards  for  AFMSS  were  developed. 
Specifically  a  Unit  Level  Open  System 
Architecture  (ULOSA)  was  specified  for 
system  interoperability  and  data 
communications  and  for  the  system 
environment  (e.g.,  operating  system, 
windows,  user  interface).  For  MCG&I  data  a 
Common  Mapping  System  (CMS)  standard 
was  developed.  ULOSA  and  CMS  are 
discussed  in  sections  5  and  7,  respectively. 

4.  TECHNOLOGY  TRENDS 
It  is  the  advances  in  computer  communications 
technology  (Ref.  4)  that  make  meeting  the 
technical  challenges  outlined  in  section  2 
possible  and  allow  us  to  build  highly  capable 
aircraft  mission  planning  systems.  Even 
though  the  standards-based  architecture  results 
in  substantial  performance  penalties,  they  are 
becoming  acceptable  because  of  lower 
cost/performance  ratios  of  hardware  and 
improved  performance  of  the  COTS  standard 
packages.  We  believe  the  development  and 
performance  objectives  discussed  in  section  2 
can  be  met  with  a  standards-based 
architecture.  Both  the  speed  and  storage 
capacity  of  integrated  circuits  are  growing  by 
about  two  orders  of  magnitude  per  decade 
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Figure  la.  AFMSS  System  Architecture 
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Figure  1b.  AFMSS  Hardware  Architecture 
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(Ref.  5).  Figure  2  (from  Ref.  2)  indicates  that 
the  trend  in  compute  power  will  bring  us  to 
500-1000  times  that  of  a  VAX  11/780  by  the 
year  2000.  Several,  popular  workstations 
costing  under  U.S.  $100,000  are  indicated  on 
the  chart.  It  is  the  availability  of  these 
powerful,  low  cost  off-the-shelf  workstations 
that  make  rapid  response  times  and 
manipulation  of  large  amounts  of  data  using 
standard  packages  feasible. 

In  addition  to  impressive  levels  of  CPU 
power,  high-end  workstations  provide  capable 
graphics  subsystems.  These  subsystems, 
employing  coprocessors  and  application 
specific  integrated  circuits,  provide  the  high 
drawing  rates  needed  to  speed  display 
response  times,  while  off-loading  the  main 
CPU  from  compute  intensive  rendering  tasks. 
Although  the  hardware  in  these  subsystems  is 
proprietary  and  unique  to  each  vendor,  the 
graphics  standards  such  as  PHIGS+,  are 
layered  on  top  of  the  operating  system  device 
driver  which  connects  to  this  proprietary 
hardware.  Thus,  the  details  of  the  hardware 
are  hidden  from  the  programmer,  and  the 
application  program  can  remain  portable 
across  multivendor  platforms. 

Another  technology  driver  is  storage. 
Commercial  workstations  with  virtual  memory 
operating  systems  can  support  many  gigabytes 
of  on-line  disk  storage,  employing  multiple 
disk  drives.  The  amount  of  storage  provided 
in  a  system  is  dictated  by  the  cost,  weight,  and 
physical  size  limitations  of  the  individual 
drives.  For  example,  today's  state-of-the-art 
in  3.5-inch  form  factor  disk  drive  is  capable  of 
storing  over  a  gigabyte  of  data  and  costs 
approximately  U.S.  $5,000.  Capacities  per 
drive  are  doubling  every  12  to  18  months  with 
price  per  device  remaining  constant.  In  multi¬ 
workstation  mission  planning  systems,  on¬ 
line  disk  storage  capacities  can  be  leveraged 
by 


providing  access  to  common  data  via  a  local 
network.  At  the  present  time,  four  to  six 
gigabytes  of  on-line  storage  represent  a 
reasonable  weight,  cost,  performance  trade¬ 
off. 

The  increased  processing  power  of 
workstations  is  being  matched  by  performance 
improvements  in  portables  and  laptops. 
Portable  mission  planners  with  MCG&I 
displays,  image  manipulations,  and  adherence 
to  open  architecture  standards  are  becoming  a 
reality,  though  our  studies  indicate  that  quality 
of  maps  and  response  times  are  still 
"marginal"  (Table  4). 

Standardized  Local  Area  Network  (LAN) 
products  that  support  data  bandwidths  of  a 
few  megabits  per  second  are  readily  available 
off-the-shelf.  (Ethemet/IEEE  standard  802.3 
are  discussed  in  section  5.)  This  permits 
standardizing  interconnectivity  between  intel, 
ops  and  mission  planning  systems.  The  Fiber 
Data  Distribution  Interface  (FDDI)  will 
provide  an  order  of  magnitude  improvement 
over  Ethernet,  with  another  order  of 
magnitude  improvement  likely  in  the  late 
1990's  should  increased  capacities  be 
required. 

It  is  clear  that  the  trend  in  workstations  is 
toward  being  faster  and  more  capable.  Strict 
adherence  to  standards  will  allow  mission 
planning  workstations  to  be  upgraded,  either 
to  enhance  performance,  or  to  replace  older 
non-supportable  units  without  costly  software 
rewrites.  It  also  allows  successive 
generations  of  mission  planners  to  coexist  as 
die  migration  takes  place.  The  next  section 
discusses  the  standards  being  adopted  for  the 
Air  Force’s  common  mission  planner, 
AFMSS. 


CPU  POWER 
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Table  4.  Capabilities  of  Portable  Computers 


Full  Laptop 

Mono  Suitcase 

Color  Suitcase 

Hardware  Cost  (35.%  off  list) 

$11,000 

$13,000 

$20,000  " 

Weight  (lb) 

(includes  transit  case,  printer) 

30  +battery 

35  +battery 

38  +battery 

Print  Maps 

Vector  Maps 
Only 

Vector  Maps 
Only 

Vector  Maps 
Only 

Interface  to  External  Systems 

floppy,  Modem, 
Serial,  Network 

Floppy,  Modem, 
Serial,  Network 

floppy.  Modem, 
Serial,  Network 

Estimated  Response  Time  for  Route 
Evaluation  (vs  2  sec) 

35  sec 

26  sec 

6  sec 

Displays 

Maps 

Vector  Only 

Vector  Only 

Vector  Only 

Threat  Depiction,  ADRI 
Perspective  View,  Radar 
Prediction  and  EO/IR 

Limited 

Greyscale,  Slow 
Response 

Limited 

Greyscale,  Slow 
Response 

Yes 

Estimated  Response  Time  for  Radar 
Prediction  (vs  12  sec) 

190  sec 

120  sec 

28  sec 

ULOSA  Compliance 

Yes 

Yes 

Yes 

Secure  OS 

Yes 

Yes 

Yes 

Key  Limitations 

Limited  Disk 
Space 

No  Expansion 
Slots 
NoEOD 

NoEOD 

5.  ULOSA  STANDARDS 
A  Unit  Level  Open  System  Architecture 
(ULOSA)  standard  that  takes  advantage  of 
trends  in  commercial  developments  has  been 
developed  to  provide  a  standard  for  physical 
and  electronic  exchange  of  information 
between  systems  and  to  allow  for  the 
rehosting  of  software.  The  ULOSA  standard 
was  originally  developed  by  The  MITRE 
Corporation  in  support  of  ESD  to  provide  an 
interoperability  standard  for  Tactical  Air  Force 
unit  level  systems  including  mission  planning, 
intelligence  systems  (e.g..  Sentinel  Byte)  and 
operational  systems  (e.g.,  WCCS).  Based  on 
common  commercial  and  military  standards  it 
was  designed  to  take  maximum  advantage  of 
existing,  working,  commercially  available 
products.  Its  primary  purpose  is  to  define  a 
standard  to  facilitate  interoperability  for  unit 
level  systems.  It  does  not  replace  system-to- 
system  interface  control  documents  which 
stipulate  the  actual  data  format  content  to  be 
transferred.  Additionally  it  seeks  to  establish 


commonality  for  unit-level  system 
environments  (e.g.,  graphics  processing, 
operating  systems)  and  to  further  enhance 
portability  and  extensibility. 

In  the  area  of  interoperability,  the  standard 
covers  unit-level  network  protocols  and 
services,  extensions,  and  management;  a 
transition  plan  to  Government  Open  System 
Interconnect  Profile  (GOSIP);  non- network 
intersystem  communications;  and  security 
constraints.  A  key  element  was  the 
preservation  of  all  levels  of  data  exchange 
mechanisms  typically  found  in  the  field- 
floppy  disk,  synchronous  and  asynchronous 
serial,  and  network.  This  is  critical  when 
systems  are  rapidly  deployed  to  unprepared 
facilities. 

In  the  area  of  system  environment  the  standard 
covers  graphics  processing,  database  query, 
operating  system  interfaces,  windowing  and 
data  element  standardization.  In  addition. 
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standards  for  interchange  formats  for  word 
processing,  spreadsheets,  imaging,  graphics 
are  recommended.  Table  5  provides  a 
summary  of  the  recommended  standards. 

These  standards  continue  to  evolve  and,  as 
later  discussed  in  this  paper,  continue  to  have 
performance  and  portability  implications.  The 
choice  of  the  "perfect"  set  of  standards  results 
in  extensive  controversy.  An  evolving,  yet 
compatible  set  of  standards  is  inevitably  the 
best  compromise.  Nevertheless 
standardization  is  necessary  if  re-usability  and 
portability  are  to  be  achieved.  We  have 
preferred  approaches  that  invited  compliance 
motivated  by  cost  and  schedule  savings,  or 
compliance  that  results  by  common  usage, 
rather  than  mandating  compliance. 

The  ULOSA  standard  will  continue  to  evolve 
as  future  technologies  and  standards  solidify: 
TCP/IP  will  evolve  to  GOSIP  with  the 
expected  co-existence  of  TCP/IP  and  GOSIP 
protocol  suites  for  some  time  (figure  3).  In 
addition  Ethernet  will  evolve  to  Fiber 
Distributed  Data  Interface  (FDDI)  with 
approximately  100  megabits/second  capacity 
and  ultra  high  speed  LAN's  (from  one  to  six 
gigabits/seconds)  if  higher  communication 
transfer  rates  are  required. 

Some  key  issues  which  remain  arc: 

•  ULOSA  recommends  OSF  MOTIF  for 
common  "look  and  feel;"  however,  a  clear 
standard  has  yet  to  emerge.  ULOSA  also 
recommends  PHIGS  for  2D/3D  Graphics; 
however,  GKS  and  proprietary  graphics 
packages  still  prevail  in  the  marketplace. 
We  believe,  based  on  recent 
research/product  evaluations,  that  the 
PHIGS  extension  to  X  windows  (PEX)  is 
the  likeliest  candidate  for  a  single  graphics 
software  standard  to  support  mission 
planning  (Ref.  2). 

•  The  implications  of  the  co-existence  of 
such  standards  as  Ada,  POSIX-compliant 
operating  systems  and  X-Windows  has 
not  been  fully  evaluated.  In  some  cases 
the  binders  between  these  products  and 
other  standards  are  not  yet  commercially 


available,  especially  since  "C"  is  more 
frequently  used  in  the  POSIX/Unix  world 
than  Ada. 

•  ULOSA  does  not  specify  a  software 
architecture.  The  role  of  object  oriented 
design  and  methods  for  ensuring  software 
re- usability  are  still  under  investigation. 
Clearly,  however,  the  software 
architecture  is  the  key  to  the 
expandability/adaptability  of  the  system 
(Ref.  6).  For  AFMSS,  industry  has  been 
tasked  to  develop  an  aircraft  specific 
interface  to  the  common  Air  Mission 
Planner  to  define  this  architecture.  This 
experience  should  prove  very  valuable  in 
specifying  software  architectures  for 
mission  planners  in  the  future. 

6.  GRAPHICS  WORKSTATION 
PERFORMANCE 

There  are  several  types  of  graphics  displays 
used  in  a  typical  mission  planning  operation: 

1 .  Plan  views  of  maps  and  images 

2.  Profile  views  of  terrain  and  routes 

3.  Overlays  of  threats  targets,  routes, 
contours,  zones,  and  weather 

4.  Projections  of  electro-optical  and  radar 
screens 

5 .  Perspective  views  of  imagery,  features 
(DFAD),  and  obstructions  (PVOD) 
over  elevation  (DTED) 

These  will  be  used  in  conjunction  with  a  user- 
system  interface  consisting  of  the  usual 
collection  of  desk  top  features,  such  as  pull¬ 
down  menus  and  scroll  bars,  along  with 
movable  and  scalable  windows. 

In  order  to  generate  these  graphics  displays, 
the  graphics  services  needed  include  raster 
operations  (i.e.,  bit  mapped  displays),  vector 
drawing  of  lines  in  two  and  three  dimensions, 
drawing  of  polygons  in  two  and  three 
dimensions  (Ref.  7),  area  fills,  and  drawing 
of  text/symbols.  The  extent  to  which 
standards  provide  these  services  is  shown  in 
Table  6. 


Transfer  Formats 
Word  Processing  Files 
Spreadsheet  Files 
Imagery  Files 
Graphics 

Weather _ 


ASCII.  ODA 
ASCII 
NITF 

CGM,  IGES,  orDXF 
FCM-S2-1986 


System  Environment 

Windowing 

X  Window  System 

Data  Element  Standardization 

JINTACCS 

Database  Query 

SQL 

Graphics  Processing 

PHIGS 

Ooeratinq  System  Interface 

POSIX 

09  Protocol  Layers 

LAN  Standards 

Point-to-Point  Standards 

Application 

File  Transfer 

Mail 

Virtual  Terminal 

Name  Services 

FTP 

SMTP 

Telnet 

Domain  Name  System 

FTP  over  SLIP,  KERMIT 

X.400 

Telnet  over  SLIP 
none 

Transport 

TCP,  UDP 

Network 

IP.  ICMP 

SLIP 

Data  Link 

802.2,  SNAP, 

Ethernet  V2.0 

Physical 

802.3, 

Ethernet  V2.0 

RS-232,  FtS-449/422. 
MIL-STD-188-1 14 

Tables.  ULOSA  Standards 


Application  Layer  Gateway 


Figure  3.  Application  Protocol  Translation 
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Table  6.  Functional  Capabilities  of  Graphics  Standards  for  Mission  Planning 


Function 

■arami 

wm  i  m  m 

PHK55+ 

5K3 - 

2b  Drawing  Functions: 

Raster  Operations 

Yes 

No 

No 

No 

Vector  Draw  . 

Yes 

Yes 

Yes 

Yes 

Text  and  Symbol  Draw 

Yes 

Yes 

Yes 

Yes 

Polygon  Draw 

Yes 

Yes 

Yes 

Yes 

Area  Fill 

Yes 

Yes 

Yes 

Yes 

3D  Drawing  Functions: 

Polygon  Draw 

No 

Yes 

Yes 

No 

Vector  Draw 

No 

Yes 

Yes 

No 

Text  and  Symbol  Draw 

No 

Yes 

Yes 

No 

Advanced  Rendering: 

Smooth  Shading;  Lighting 
Models;  Depth  Cueing 

No 

No 

Yes 

No 

Archival  Storage 

No 

Yes 

Yes 

Yes  1 

Editable  Display  List  Storage 

No 

Yes 

Yes 

No 

Support  for  Multiple  Windows 

Yes 

No 

No 

No 

Networked  Operation 

Yes 

No 

No 

No 

While  X  Windows  handles  displays  of  raster 
maps  and  image-based  data  such  as  satellite 
photography,  it  lacks  functions  to  employ  the 
workstations  rendering  hardware  to  generate 
geometric-based  terrain  visualizations,  such  as 
a  drape  of  (DFAD)  features  over  (DTED) 
elevations.  On  the  other  hand,  the  PHIGS+ 
standard  can  support  highly  realistic, 
geometry-based  terrain  visualizations  handily 
with  its  3D  drawing  primitives,  but  is 
incapable  of  dealing  with  raster  images  and, 
therefore  with  the  display  of  digitized  maps. 
GKS  falls  short  in  both  of  these  areas. 

There  is  very  little  data  on  response  times  of 
workstations  utilizing  standards  in  its  server 
software  packages.  Our  experience  indicates 
that  the  response  times  in  Table  3  can  be  met 
by  workstations  in  the  U.S.  $25,000  to 
$50,000  range  using  their  native  graphics 
libraries.  Some  of  these' response  times  are 
already  longer  than  ideal.  The  addition  of 
standards  such  as  X  Windows  and  PHIGS 
adds  additional  performance  penalties. 

Some  earlier  studies  conducted  at  MITRE 
(Refs.  8  and  9)  indicate  performance  penalties 
ranging  over  factors  from  three  to  ten  utilizing 
PHIGS  or  GKS  instead  of  native  graphics 
packages  for  2D  vector  drawings  and 
text/symbol  drawings.  Recent  measurements 
of  X  Window  performance  indicate  that  severe 


(order  of  magnitude)  performance  penalties 
exist 

With  none  of  the  current  standards  meeting 
full  functionality,  and  with  the  existence  of 
major  performance  penalties,  a  truly  portable, 
high  performance  software  graphics  standard 
solution  is  needed.  That  solution  appears  to 
be  PHIGS  extension  to  X  (PEX).  Not  only 
does  PEX  provide  all  of  the  capabilities 
required  for  mission  planning,  but  also  it 
provides  reasonable  subsets  for  compatibility 
with  different  types  of  workstations,  and  it  is 
being  provided  as  the  native  graphics  library 
by  some  vendors.  It  is  the  latter  which  gives 
the  greatest  encouragement  by  promising  the 
kind  of  performance  previously  achieved  only 
by  proprietary  graphics  packages.  This  kind 
of  standardization  and  performance  will  permit 
the  portability,  affordability  and  quality  of 
display  manipulations  required  by  mission 
planning. 

7.  COMMON  MAPPING  SYSTEM 
A  mission  planning  system  relies  heavily  on 
Mapping,  Cartography,  Geodesy  and  Imagery 
(MCG&I)  data.  Worldwide  coverage  of  all 
types  of  digitized  MCG&I  data  requires 
approximately  two  to  three  terrabytes  of 
storage.  Traditionally,  paper  charts  have  been 
digitized;  and  uncompressed,  unmodified 
Defense  Mapping  Agency  digital  products 
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have  been  available  organized  by  data  type 
(e.g.,  Digital  Terrain  Elevation  Data,  Digital 
Feature  Analysis  Data,  World  Vector 
Shoreline).  However,,  the  aggregate  volume 
of  data  becomes  prohibitively  large  and 
unmanageable  for  field  users,  such  as  mission 
planners,  whose  area  of  operation  are  large 
and  variable.  (Typical  MCG&l  products  and 
their  storage  requirements  are  provided  in 
Table  7.)  This  has  led  to  use  of  non- 
standardized,  proprietary  format,  compressed 
data  which  has  been  costly  to  acquire, 
reproduce,  store  and  distribute. 

With  hundreds  of  gigabytes  of  data  required 
for  planning  on  a  workstation,  there  is  a  need 
to  both  index  the  information  for  rapid  access 
and  to  develop  compression/reduction 
techniques.  Furthermore,  there  is  a  need  to 
provide  this  data  in  a  standardized,  digitized 
format  in  the  public  domain  and  available  with 
worldwide  coverage.  At  the  current  disk  drive 
cost  of  approximately  U.S.  $5,000/gigabyte, 
the  data  needs  to  be  reduced/compressed  to 
provide  affordability  and  portability  of  the 
system.  By  providing  regional  storage  and 
flexibility  of  access,  terrabytes  can  be  reduced 
to  200  gigabytes,  and  by  further 
reduction/compression  by  factors  of  48:1,  the 
amount  of  on-line  storage  can  be  reduced  to 
four  to  six  gigabytes  while  maintaining  the 
quality  of  the  displayed/printed  material.  Such 
considerations  have  led  the  U.S.  Air 
Force/ESD  to  develop  a  Common  Mapping 
System  (CMS)  standard  for  MCG&I  data. 

CMS  initially  consists  of  a  standardized, 
cartographic  datebase  structure.  It  will  be 
augmented  in  the  future  with  a  set  of  standard 
software  functions  (toolkits)  for  exploiting  the 
database,  and  a  suite  of  tests  for  verifying  that 
any  given  application  has  correctly 
implemented  the  database  structure  and  the 
related  functions.  CMS  uses  the  World 
Geodetic  System  (WGS-84)  model  of  the 
earth's  surface,  to  which  all  products  are 
referenced.  The  database  structure  organizes 
data  in  1°  X  1°  geocells  for  file  access. 
Related  data  type  can  be  stacked  for  matching 
geocells  (Figure  4).  It  also  provides  for 
specifying  the  data  compression/reduction 
method  used. 


By  providing  operationally  selectable  areas 
and  appropriate  compression/reduction  of 
48:1,  four  to  six  gigabytes  of  on-line  storage 
can  be  used  to  provide  the  following  coverage: 

GLOBAL:  Worldwide  coverage  containing 
WVS,  ADRG  GNC  and  JNC 
charts,  and  DAFTF 

AREA:  Theatre-wide  coverage 

(equivalent  to  the  coverage  of 
one  JNC  chart)  containing 
ADRG  ONC  and  TPC  charts, 
DCW  data  and  DTED  Level  1 
(250,000  square  nautical  miles) 

KERNEL:  Kernel  set  of  70  user  selected 
geocells  (one  degree  by  one 
degree)  containing  DTED  and 
DFAD  Level  1,  ADRG  JOG-Air, 
PVOD,  and  either  ADRG  TLM 
orADRI. 

An  example  of  this  particular  configuration  is 
depicted  in  example  1  (Figure  5).  Additional 
configurations  using  the  same  amount  of 
storage  but  different  allocation  of  products  are 
depicted  in  example  2  (Figure  6)  and  example 
3  (Figure  7). 

In  performing  investigations  of 
compression/reduction  techniques  in  the 
laboratory,  MITRE  has  found  that  48:1  and 
even  96:1  reduction  compression  ratios  are 
feasible  while  maintaining  both  display  and 
printer  quality.  Quality  Judgment  Criteria 
were  background  stipple  and  moire,  legibility 
and  aliasing  of  fine  print  differentiation  of 
rivers  and  contour  lines,  preservation  of 
symbology,  and  color  fidelity.  The  work 
researched  several  spatial  reduction  techniques 
to  achieve  4:1  spatial  reduction.  Of  the  filters 
investigated,  neighborhood  averaging  gave  the 
worst  results  and  a  separable  cubic  filter  gave 
very  good  results. 

The  standard  vector  quantization  (VQ) 
technique  Linde  Buzo  Gray  (LBG)  was  found 
to  produce  fairly  poor  results  at  4:1 
compression.  However,  other  vector 
quantization  techniques,  especially  "pairwise 
nearest  neighbor,"  resulted  in  acceptable 
quality,  provided  color  quantization  (3:1)  was 
well-integrated  with  VQ.  Custom  color  table 
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Table  7a.  MCG&I  Products  and  Storage  Requirements 


MCG&I  Product  Sizes:  Per-Product 


Product 

E3T91 

Scale 

Typical 
Coverage 
(lat  x  long 
@  45®  lat) 

Original 

Paper 

Size 

(inches) 

Total 
No.  of 
Charts 

Original 

Data 

Size 

(per 

chart) 

Original 

Data 

Volume 
(per  series) 

Compressed 

Data 

Size 

(per  chart) 

Compressed 

Data 

Volume 
(per  series) 

ADRG 

GNC  Series 

Raster 

1:5M 

45^x60^ 

40x60 

27 

380  MB 

10  GB 

7.9  MB 

0.21  GB 

ADRG 

JNC  Series 

Raster 

l:2M 

16^ x  32s 

40x60 

122 

380  MB 

46  GB 

7.9  MB 

0.96  GB 

ADRG 

ONC  Series 

Raster 

1:1M 

8°  x  16° 

40x60 

270 

380  MB 

100GB 

7.9  MB 

2.1GB 

ADRG 

TPC  Series 

Raster 

1:500K 

40x60 

893 

380  MB 

340  GB 

7.9  MB 

7.1  GB 

ADRG 

JOG-Air 

Series 

Raster 

1 :250K 

m 

22  x  29 

3,401 

120  MB 

400  GB 

2.5  MB 

8.5  GB 

ADRG 

JOG-Grnd 

Series 

Raster 

1 :250K 

m 

22x29 

5,045 

120  MB 

590  GB 

2.5  MB 

13GB 

ADRG 

TLM  Series 

Raster 

1:50K 

22  x  29 

m 

70  MB 

— 

1.5  MB 

— 

WVS 

tV-MMJi 

1 :250K 

Worldwide 

n.a. 

QQH 

n.a. 

170  MB 

n.a. 

170  MB 

DOW 

Vector 

1:1M 

Worldwide 

n.a. 

n.a. 

n.a. 

10  GB 

n.a. 

DAFIF 

Text 

n.a. 

Worldwide 

n.a. 

n.a. 

n.a. 

... 

n.a. 

... 

Table  7b.  MCG&I  Products  and  Storage  Requirements  (Concluded) 


MCG&I  Product  Sizes:  Per-Geocell 


Product 

Data  Tvpe 

Scale 

Compressed 

Data 

Volume 

DTED  Level  1 

Gridded 

2.95  MB 

DTED  Level  2 

G  ridded 

27  MB 

DFAD  Level  1 

Vector 

0.4  MB 

DFAD  Level  1C 

Vector 

DFAD  Level  2 

Vector 

DFAD  Level  3C 

Vector 

PVOD 

Vector 

0.5  MB 

JOG-Air 

Raster 

1:250K 

1.2MB<D 

JOG-Grnd 

Raster 

1:250K 

1.2  MB<>> 

TLM 

Raster 

T.50K 

29  MB'1* 

ADRl 

Rastar 

1-.50K 

29  MB(2> 

Notes:  I)  Compressed  48:1  from  original  DMA  density 

2)  Compressed  4:1  from  source  data  density  (I  byte/pixel) 


DRI 


■KUMiliHgiSillRlil 

mmm 


Figure  4.  CMS  Database 


Geocell 


2?0,Q00sqnmJ' 


S:  220,000  so  nm 


{2.SGBJ'' 


Hgure  5.  Example  1 
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techniques  were  needed  to  maintain 
compatibility  with  VQ  compression  schemes. 
Additional  work  is  still  required  to  specify 
standards  for  "quality"  of  displayed  and 
printed  maps. 

Mission  planning  requirements  for  paper 
usable  under  high  temperature/intense  sunlight 
conditions,  when  night  vision  conditions,  and 
with  acceptable  grey  scale  reproductions, 
color,  contour  line  legibility,  printer  speed, 
and  paper  size  still  push  the  state  of  the  art  of 
printers  if  required  to  be  available  in  a  single 
printer.  Media  costs,  which  vary  from  less 
than  U.S.$1.00  to  $8.00  per  page  also  play  an 
important  role  in  choosing  an  affordable 
mission  planner. 

Image  data  presents  additional  problems  for 
two  reasons:  sheer  quantity  of  data  and  the 
need  for  real-time  transmission  of  some 
imagery  data.  Satellite  image  data  has  recently 
been  found  by  the  user  to  be  a  particularly 
useful  planning  tool.  In  addition  to  being 
used  for  terrain  perspective  views  and  fly- 
through,  imagery  is  being  used  for  targeting 
and  battle  damage  assessment. 

The  large  amount  of  storage  and  time  required 
to  transmit  imagery  is  a  function  of  the 
number  of  bits  required  to  represent  the 
image.  There  are  similar  techniques  for  the 
storage  and  transmission  of  data,  text  or 
imagery;  however,  the  sheer  volume  of  image 
data  causes  problems.  While  a  standard  page 
of  text  contains  25  thousand  bits  of  data,  an  8- 
bit  pixel  grey  scale  image  (1024  x  1024 
pixels)  contains  over  8  million  bits  and  an 
equivalent  size  24  bit/pixel  color  image  over 


25  million  bits.  Typical  transmission  times 
for  text  (one  page)  and  imagery  (1024  x  1024 
pixels)  are  given  in  Table  8. 

These  numbers  represent  transmission  times 
for  uncompressed  data.  Algorithms  yielding 
compression  ratios  of  six  to  ten,  without 
significant  loss  of  legibility,  currently  exist; 
however,  they  can  have  significant  cost  and 
processing  penalties. 

8.  FUTURE  CHALLENGES 
Some  of  the  near-term  challenges  have  already 
been  indicated  in  this  paper.  These  include  the 
development  of  a  software  architecture  that 
supports  the  addition  of  new  aircraft  and 
updates  of  avionics  software;  meeting 
performance  goals  with  standard  graphics 
packages,  and  providing  useful  mission 
planning  capabilities  on  a  "portable"  mission 
planner.  Others  include  moving  map 
displays,  standardizing  on  threat  models, 
evaluating  and  testing  automated  routing  aids, 
ensuring  the  availability  of  required  data,  such 
as  weather  data,  and  maintaining  timeliness 
and  integrity  of  huge  databases.  The  goal  is  to 
provide  an  interoperable  mission  planner  that 
can  be  used  by  any  aircraft  assigned  to  a  base. 

Future  technology  challenges  include 
incorporation  of  Artificial  Intelligence 
techniques,  including  "learning"  from 
previous  missions,  interfacing  with  mission 
rehearsal  systems,  in  flight  route/target 
updates,  and  taking  advantage  of  technology 
breakthroughs  in  such  areas  as  natural 
language  interfaces  and  virtual  reality. 


Table  8.  Transmission  Times  (In  Minutes) 


Data  Rate 

Text 

(One  Page) 

RS! m 

Color 

(1024  x  1024  pixels) 

Commercial  Channel 

56000  bits/sec 

.01 

2.5 

7.5 

Tactical  Channel 

16000  bits/sec 

.03 

8.7 

26.2 

Telephone  or  FAX 

9600  bits/sec 

.04 

14.6 

43.7 

1200  bits/sec 

.35 

116.5 

349.5 
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1.  SUMMARY 

Pluming  an  airborne  search  for  a  relocatable  target 
involves  minimizing  the  risk  to  the  crew  while  maximizing 
the  estimated  likelihood  of  finding  targets.  When  the 
number  of  potential  sites  is  small,  the  problem  reduces  to 
finding  the  best  (usually  the  shortest)  route  connecting 
them.  The  aircraft  need  not  overfly  each  site,  but  must  only 
come  within  sensor  range  of  it.  Thus,  the  search  route 
planning  problem  can  be  modeled  u  a  covering  salesman 
problem  (CSP)  -  a  generalization  of  the  traveling  salesman 
problem  in.  which  the  tour  need  not  visit  every  city,  but 
every  city  must  be  within  a  certain  distance  of  some  city  on 
the  tour.  The  spacefilling  curve  heuristic  for  the  traveling 
salesman  problem  is  demonstrated,  then  a  new  heuristic  for 
the  covering  salesman  problem  is  presented  and  applied  to 
the  search  route  planning  problem.  When  the  number  of 
sites  is  luge,  the  planner  must  also  decide  which  subset  of 
them  can  be  visited.  A  genetic  algorithm  has  been 
developed  for  selecting  both  a  set  of  sites  to  visit  and  an 
appropriate  routing  pattern.  The  procedure  also  accounts 
for  the  finite  turning  radius  of  the  aircraft. 


This  can  be  modeled  as  a  planar  traveling  salesman 
problem,  which  is  efficiently  solved  by  the  heuristics  of 
section  2. 

However,  the  aircraft  need  not  overfly  each  site,  but  must 
only  come  within  sensor  range  of  it.  An  overflight  of  one 
site  may  provide  adequate  sensor  coverage  of  nearby  sites 
as  well.  This  becomes  significant  if  intenite  distances  can 
be  comparable  to  the  effective  sensor  range,  giving  us  the 
partial  ordering 

“  Rnu  «Ran.«  Rfli,*  (5) 

This  can  be  modeled  as  a  planar  covering  salesman 
problem,  which  is  also  discussed  in  section  2  and  appendix 
A.  In  this  case,  the  search  route  planning  problem  can  be 
modeled  as  a  covering  salesman  problem  (CSP)  as 
formulated  by  Current  and  Schilling  [IJ.  The  CSP  is  a 
generalization  of  the  traveling  salesman  problem  in  which 
the  tour  need  not  visit  every  city,  but  every  city  must  be 
within  a  certain  distance  of  some  city  on  the  tour. 


1.1  Characteristic  Distances 

First,  it  may  help  to  systematically  introduce  the 
constraints  on  the  search  routing  problem.  Several 
important  aspects  of  the  problem  may  be  described  by  a  set 
of  characteristic  distances: 


Rmrn.  the  minimum  turning  radius, 

Rteiuor>  sensor  range, 

Rnu.  the  typical  intersite  distance, 

Rerm>  ^  diameter  of  the  search  area,  and 

RfUfkr  die  flight  distance  permitted  by  time  and  fuel 

constraints 

We  may  expect  at  least 


Assume  there  are  n  sites.  If  the  search  area  were  square  and 
the  visited  sites  were  distributed  uniformly,  the  length  of 
the  shortest  tour  would  be  roughly  •/»  Korea  (see  appendix 
A).  A  fuel  or  flight  time  constraint  becomes  significant 
only  when  it  means  that  not  all  sites  can  be  covered.  In 
terms  of  these  characteristic  distances,  this  corresponds  to 
the  case 


l  <  R/ti$kt  R  a 


(6) 


The  assumption  of  small  turning  radius  is  appropriate  for 
high  altitude  searching,  because  of  the  necessarily  large 
sensor  range  in  that  case.  It  is  not  valid  for  low  altitude 
searching.  The  general  low  altitude  case  is  then 


. «  R _ <  R 


fli/la 


(1) 


-  R  -  R 

I  inter  It 


. «  R _ <  R, 


yi>r*< < 


r*  R. 


(7) 


so  the  aircraft  can  fly  across  the  search  area  and  maneuver 
within  it. 

Rtnter  <<  R  ana  (7) 

so  the  sensor  can  cover  only  a  small  part  of  the  search  area 
at  once,  and 

Rtitt  <<  Rana  (7) 

so  the  search  area  contains  several  sites.  The  simplest 
situation  is 

Rtam  <  ^  R  uner  «**.«  R~m«RfUtt*  <4> 


1.2  Overview 

Section  2  discusses  the  CSP,  and  heuristics  for  their 
approximate  solution.  Section  3  shows  how  a  flight  path 
can  be  constructed  which  accounts  for  the  finite  turning 
radius  of  the  aircraft. 

When  the  number  of  potential  sites  is  large,  the  aircraft’s 
time  and  fuel  constraints  may  preclude  visiting  all  of  them. 
The  planner  must  then  decide  which  of  them  are  to  be 
visited.  Section  4  extends  the  above  procedure  to  include 
the  selection  of  an  appropriate  set  of  sites.  The  new 
procedure  also  evaluates  alternative  routing  patterns  and 
accounts  for  the  finite  turning  radius  of  the  aircraft. 

Selection  of  the  sites  to  visit  is  handled  by  imbedding  the 
heuristic  router  within  an  optimization  program.  The  outer 
program  selects  a  set  of  sites  to  be  visited.  The  heuristic 


router  finds  a  search  route  covering  those  sites.  The  outer 
program  computes  a  score  for  the  route.  It  then  adjusts  the 
sites  to  be  visited  in  an  attempt  to  optimize  the  score 
(while  satisfying  time  and  fuel  constraints)  and  repeats. 
For  this  combinatorial  optimization  problem,  a  genetic 
algorithm  is  used. 

Section  5  displays  typical  results.  A  concluding 
discussion  appears  in  section'  6. 

2.  ROUTING  PROBLEMS 

2.1  The  Traveling  Salesman  Problem 

In  the  traveling  salesman  problem  (TSP),  one  is  given  a  set 
of  cities  and  a  table  of  intercity  distances,  and  is  required  to 
find  a  tour  which  visits  all  the  cities  while  minimizing  the 
total  distance  traveled. 

In  the  Euclidean  TSP.  the  graph  is  complete  (so  that  travel 
is  permitted  between  any  two  cities)  and  the  intercity 
distances  are  calculated  bom  the  city  locations  using  the 
Euclidean  metric.  We  will  be  concerned  with  air  travel 
among  sites  in  a  small  region,  which  is  well  modeled  by  the 
planar  (two-dimensional)  Euclidean  TSP. 

The  TSP  is  NP-hard,  as  discussed  by  Carey  and  Johnson  [2]. 
This  means  that  the  time  required  to  find  the  exact  solution 
to  a  problem  with  n  cities  increases  faster  than  any  fixed 
power  of  n,  and  that  for  practical  purposes,  large  problems 
(thousands  of  cities)  cannot  be  solved  exactly.  However, 
there  are  a  number  of  heuristics  for  the  TSP  which  give  good 
solutions  (i.e„  within  a  few  percent  of  the  length  of  the 
optimal  solution). 

2.1.1  The  Spacefilling  Curve  Heuristic  for  the  TSP 
Bartholdi  and  Platzman  have  found  a  heuristic  for  the  planar 
TSP  [3]  using  a  spacefilling  curve  due  to  Sierpinski.  which 
is  a  continuous  map  9  from  the  unit  interval  C  =  [0,1]  onto 
the  unit  square  S  =  [0.1 12.  Sierpinski's  curve  is  the  limit  of 
the  sequence  shown  in  figure  1.  It  is  a  closed  curve  in  which 
0  and  1  are  mapped  to  the  lower  left  comer. 


Flgura  1.  Approximations  to  Slsrpinski's 
Spacefilling  Curve 


Their  heuristic  solution  to  the  planar  TSP  is  as  follows: 
HEURISTIC  TSP  - 1 

a.  For  each  point  p  e  [0.1  J2  to  be  visited,  find  a  key 
0  suck  that  p  »  0(6). 

b.  Sort  the  points  by  their  corresponding  9s. 

c.  Visit  the  points  m  order  of  increasing  0,  then 
return  to  the  first  point. 

The  feasibility  of  this  procedure  rests  on  an  efficient 
algorithm  for  computing  the  9  values,  or  keys.  Given  n 


points,  the  keys  may  be  computed  and  sorted  in  0(n  log  n) 
time  or,  using  BINSORT.  in  O(n)  expected  time. 

The  method  is  illustrated  in  figure  2,  where  the  city 
locations  have  been  chosen  to  lie  on  the  curve  at  the  second 
level  of  refinement.  The  resulting  tour  visits  the  cities  in 
the  same  order  as  the  spacefilling  curve. 


Figura  2.  llaing  a  Spacefilling  Curve  to  Find 
a  Tour 


The  same  method  can  be  extended  to  Euclidean  traveling 
salesman  problems  in  higher  dimensions,  using  higher 
dimensional  spacefilling  curves  [4], 

This  heuristic  produces  efficient  tours  because  a 
spacefilling  curve  preserves  nearness:  points  close 

together  in  C  map  (via  $)  onto  points  close  together  in  S. 
In  S  we  use  the  Euclidean  measure  denoted  by  \pt  -  pf. 
Sierpinski's  curve  is  a  circuit  with  9(0)  =»  9(1),  so  the 

natural  metric  on  C  is  D(0.0')  ■  min{|0-0'|.l-|0-0(} .  Its 
nearness  property  may  be  staled  formally  as  [3]: 

w> 51  <» 

Since  C  is  one  dimensional  and  S  is  two  dimensional,  it 
should  perhaps  not  surprise  us  that  a  distance  in  S  tends  to 
be  proportional  to  the  square  root  of  the  corresponding 
distance  in  C.  (For  a  spacefilling  curve  mapping  C  to  *- 
space,  a  distance  in  fc-space  tends  to  be  proportional  to  the 
kth  root  of  the  corresponding  distance  in  C.)  Note  that 
there  is  no  corresponding  bound  on  the  inverse  of  R.  so 
while  nearness  along  C  guarantees  nearness  in  S,  the 
converse  does  not  hold.  That  is.  points  nearby  in  5  are 
only  likely  to  correspond  to  points  nearby  in  C. 

2.1.2  Tour  Improvement 

For  TSPs  in  which  the  cities  are  distributed  uniformly  on 
the  unit  square,  TSP-1  generates  tours  which  are  about  25 
percent  longer  than  the  expected  length  of  the  optimal  tour 
[3],  These  heuristic  tours  often  have  fairly  obvious 
inefficiencies. 

Platzman  and  Bartholdi  [4]  have  also  described  an 
improvement  procedure  which  perturbs  the  location  of  each 
point  just  enough  to  change  its  position  in  the  tour  and 
keeps  the  changes  that  shorten  the  tour.  On  average,  the 
enhanced  heuristic  gives  tours  about  13  percent  longer  than 
optimal,  and  still  takes  0(n  log  n)  time.  We  will  refer  to  it 
as  TSP-1 

TSP-2  was  used  to  find  a  tour  through  100  cities  placed 
randomly  in  a  square.  The  resulting  tour  is  shown  in  figure 
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Figure  3.  Example  of  a  Heuristic  Tour 
through  100  Cities  in  s  Square 

2.1.3  Open  Tours 

A  search  route  for  an  aircraft  should  begin  and  end  at  the 
edge  of  the  search  region,  but  need  not  begin  and  end  at  the 
same  point.  In  fact,  it  is  usually  best  if  the  beginning  and 
ending  points  are  widely  separated.  This  can  be  arranged  by 
using  an  open  spacefilling  curve  (i.e.,  one  that  does  not 
begin  and  end  at  the  same  point),  rather  than  the  Sierpinski 
curve. 

One  such  curve  is  Hilbert's  curve  [3],  shown  in  figure  4.  To 
illustrate  the  use  of  this  curve,  TSP-2  was  used  with  the 
Hilbert  curve  to  find  a  tour  through  the  same  100  cities  as  in 
the  previous  example.  The  resulting  tour  is  shown  in  figure 
3.  Note  that  the  start  and  end  points  are  now  in  adjacent 
corners. 


Figure  4.  Approximations  to  Hilbert's 
Spacefilling  Curve 


Figure  5.  Example  of  a  Heuristic  Tour 
Generated  Using  the  Hilbert  Curve 


2.14  Other  Heuristics  for  the  TSP 

The  "strips"  method  described  by  Karp  and  Steele  (6]  is 

an  older  heuristic  for  the  planar  TSP.  For  n  cities,  it 

consists  of  the  following: 

STRIPS  HEURISTIC 

a.  Divide  the  area  into  fit  horizontal  strips. 

b .  Sort  the  cities  along  each  strip. 

c.  Visit  the  cities  in  the  first  strip  from  right  to  left, 
then  those  in  the  second  strip  from  left  to  right, 
etc. 

The  "strips"  heuristic  can  be  implemented  in  the  seme  way 
as  the  spacefilling  curve  heuristics,  by  defining  an 
appropriate  ordering  function,  so  it  also  requires  only 
0(n  In  n)  steps.  For  large  numbers  of  sites  distributed 
uniformly  in  the  unit  square,  the  strips  heuristic  generates 
TSP  solutions  about  22  percent  longer  than  optimal  (vs.  23 
percent  over  optimal  for  the  spacefilling  curve  heuristic 
using  Sierpinski's  curve).  The  strips  heuristic  is  more 
sensitive  to  local  variations  in  site  density. 

The  "arbitrary  insertion"  heuristic  for  the  TSP  described  by 
Golden  {7]  has  also  been  adapted  to  the  search  routing 
problem  as  follows: 

ARBTTRARY  INSERTION  HEURISTIC 

a.  Start  with  a  path  directly  from  the  start  to  the 
finish. 

b.  Repeat  until  all  cities  have  been  added: 

1 .  Arbitrarily  select  city  k  not  in  the  path  to  enter 
the  path. 

2 .  Find  the  edge  (ij)  in  the  path  which  minimises 
the  cost  of  inserting  city  k  and  insert  it  there. 

The  arbitrary  insertion  heuristic  requires  OIn2)  steps.  It 
finds  TSP  solutions  about  3  percent  larger  than  optimal. 

The  arbitrary  insertion  method  could  be  used  in  a 
semiautomaled  router  in  which  an  operator  specifies  part  of 
the  route  (initial  and  final  points,  and  some  of  the 
intermediate  sites)  and  the  computer  adds  the  remaining 
sites.  The  initial  route  could  include  multiple  visits  to 
some  sites. 

The  spacefilling  and  strips  heuristics  require  a 
preprocessing  step:  the  city  locations  must  be  rotated  and 
scaled  into  the  unit  square.  This  is  not  necessary  for  the 
arbitrary  insertion  heuristic. 

2.2  The  Covering  Salesman  Problem 
The  Covering  Salesman  Problem  (CSP)  was  formulated  by 
Current  and  Schilling  (1).  It  is  a  generalization  of  the 
traveling  salesman  problem  in  which  the  tour  need  not  visit 
every  city,  but  every  city  must  be  within  a  certain  distance  d 
of  some  city  on  the  tour.  For  example,  suppose  one  is 
planning  routes  for  a  rural  health  care  delivery  team.  It  is 
sufficient  that  every  potential  patient  be  within  some 
predetermined  travel  distance  of  a  stop  on  the  route.  The 
CSP  reduces  to  the  TSP  if  d  is  sufficiently  small. 

In  our  application,  the  aircraft  must  pass  within  sensor 
range  of  each  potential  target  site.  We  will  approximate 
this  by  routing  the  aircraft  directly  over  some  subset  of  the 
sites,  such  that  every  site  not  visited  is  within  sensor  range 
of  some  visited  site. 


2.2.1  The  COVTOUk  Heuristic 

Current  and  Schilling  presented  a  heuristic  for  the  CSP 
which  they  call  COVTOUR  [1]: 

HEURISTIC  COVTOUR 

a.  Identify  the  minimum  subset  R  of  points  which 
cover  all  the  points  to  be  visited.  This  is  a  set 
covering  problem  (SCP). 

b.  Find  the  minimum  tour  connecting  the  points  in  R. 
This  is  a  TSP. 

c.  If  more  than  one  optimal  solution  to  the  SCP  was 
found  in  step  a.,  repeat  step  b.  for  each.  The 
shortest  tour  found  is  the  solution. 

Since  both  the  set  covering  problem  and  the  TSP  are  NP- 
hard  as  discussed  by  Garey  and  Johnson  [2],  this  procedure 
is  impractical  for  large  n. 

222  Fast  Heuristics 

Clearly,  one  naive  heuristic  for  the  CSP  is  to  neglect  the 
covering  distance  and  treat  it  as  a  TSP,  thereby  finding  a 
tour  that  visits  every  city.  When  the  CSP  is  Euclidean,  a 
spacefilling  curve  heuristic  can  be  devised  which  is  more 
effective:  fmd  a  heuristic  tour  through  all  the  cities,  then 
choose  a  subset  of  cities  that  will  cover  all  the  cities.  (Note 
that  solving  the  routing  problem  first  and  the  covering 
problem  second  is  just  the  opposite  of  COVTOUR.) 

This  method  for  solving  the  CSP  is  actually  an  application 
of  the  following  general  technique  proposed  by  Bartholdi 
and  Platzman  for  solving  combinatorial  problems  in  the 
plane  (8): 

GENERIC  SPACEFILLING  HEURISTIC  (GSFH) 

a.  Transform  the  problem  in  the  unit  square,  via  a 
spacefilling  curve,  to  a  problem  on  the  unit 
interval. 

b.  Solve  the  (easier)  problem  on  the  unit  interval. 

A  family  of  heuristics  of  this  type  for  a  specific  problem 
can  be  generated  by  using  different  transformations  to  the 
unit  square,  different  spacefilling  curves,  and  different 
solutions  of  the  problem  on  the  unit  interval. 

The  spacefilling  curve  heuristic  for  the  TSP  is  another 
special  case  of  the  GSFH. 

We  have  developed  several  such  heuristics,  with  different 
methods  of  selecting  the  subset  of  cities  to  be  visited. 
These  are  discussed  in  detail  in  appendix  A.  The  most 
effective  heuristic  is  the  one  we  have  called  CSP -4,  and  it  is 
the  one  used  for  the  examples  in  the  remainder  of  this 
report.  The  solution  found  by  CSP-4  for  a  sample  problem 
with  21  cities  is  shown  in  figure  6.  The  circles  indicate  the 
coverage  of  the  visited  cities. 


22  Search  Routes 

Efficient  search  routes  can  be  generated  by  combining  the 
ideas  of  the  previous  two  subsections  with  a  simple  way  to 
transform  the  candidate  target  sites  into  the  unit  square. 

In  our  application,  we  can  assume  the  sites  to  be  searched 
will  be  contained  within  a  rectangle,  and  the  search  route 
should  begin  along  one  edge  of  the  rectangle  and  end  along 
the  opposite  edge.  The  spacefilling  curve  heuristic  can 
generate  such  a  route  using  the  Hilbert  curve  if  the  rectangle 
is  suitably  transformed  into  the  unit  square.  The 
transformation  consists  of  a  rotation,  a  displacement,  and 
uniform  scaling.  (Nonuniform  scaling  is  generally  not 
helpful.)  The  final  orientation  and  spacefilling  curve  should 
be  chosen  so  that  the  search  start  and  end  points  are  near 
the  desired  ones. 

3.  FLIGHT  PATHS 

A  flight  plan  includes  a  set  of  waypoints  which  a  pine  flies 
through  in  succession.  In  this  work,  waypoints  are  two 
dimensional.  When  the  waypoints  are  well  separated,  the 
flight  path  can  be  approximated  by  straight  lines  between 
the  waypoints.  However,  for  closely  spaced  waypoints, 
high  aircraft  speeds,  and/or  restricted  aircraft  maneuver¬ 
ability,  the  finite  turn  radius  of  the  aircraft  must  be  taken 
into  account. 

By  convention,  a  flight  path  consists  of  straight  lines  ami 
circular  arcs.  One  planning  objective  might  be  to  find  the 
shortest  such  path  which  passed  through  the  specified  sites. 
It  might  be  constructed  using  the  following  manual 
procedure:  Start  with  a  flat  map  of  the  flight  area.  Insert  a 
pin  at  each  of  the  points  to  be  visited.  Drop  over  each  pin  a 
hollow  cylinder  of  a  size  corresponding  to  the  desired  turn 
circle.  Thread  a  string  around  the  cylinders  in  the  chosen 
order  and  draw  it  tight,  forcing  each  cylinder  against  its 
pin.  (We  assume  the  cylinders  do  not  interfere  with  each 
other.)  The  string  then  follows  the  shortest  path  for  the 
chosen  visitation  order. 

This  manual  procedure  generates  a  flight  path  which  visits 
each  waypoint  halfway  through  a  turn.  This  doubles  the 
number  of  significant  locations  the  navigator  must  keep 
track  of  (search  sites  plus  turn  points).  It  requires  accurate 
flying,  since  an  incotTect  airspeed  or  bank  angle  will  lead 
to  an  incorrect  turn  radius  and  possibly  a  missed  search  site. 
It  also  means  that  the  aircraft  will  never  be  level  when 
overflying  the  site.  For  these  reasons,  as  well  as 
convenience,  we  have  instead  implemented  the  simpler 
waypoint  turn  algorithm-.  The  aircraft  initiates  each  turn  as 
it  passes  a  waypoint.  The  aircraft  then  flies  along  a  turn 
circle,  with  its  center  at  a  distance  R  from  the  the  waypoint 
and  at  right  angles  from  the  original  flight  path. 
Ordinarily,  the  aircraft  turns  toward  the  next  waypoint,  as 
shown  in  figure  7.  However,  if  this  would  put  the  next 
waypoint  within  the  turn  circle,  the  turn  can  be  made  in  the 
opposite  direction  instead,  thus  adding  a  loop.  This  is 
shown  in  figure  8.  These  two  cases  suffice  to  handle 
arbitrarily  difficult  routing  problems,  such  as  the  closely 
spaced  waypoints  shown  in  figure  9. 


Figure  6.  A  CSP  Solution  Found  by  Heuristic 
CSP-4 
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GAs  are  more  generally  applicable  and  robust  than  calculus- 
baaed  methods,  and  can  be  much  more  efficient  than  random 
search  and  enumer alive  methods.  GAs  have  been  success¬ 
fully  applied  to  pipeline  control  (9].  structural  optimiza¬ 
tion  [10],  recursive  adaptive  filter  design  [11],  VLSI  circuit 
layout  [12],  and  many  other  problems. 

GAs  were  developed  by  John  Holland  and  his  colleagues  at 
the  University  of  Michigan  [13],  A  short  description  of 
GAs  appears  in  the  next  two  subsections.  A  more  extensive 
discussion  may  be  found  in  [14]. 


Figure  7.  Aircraft  Turns  Toward  Next 
Waypoint 


Figura  8.  Aircraft  Turns  Away  from  Naxt 
Waypoint 


4.1  Description 

The  genetic  algorithms  in  this  work  follow  this 
reproductive  plan: 

GENETIC  ALGORITHM 

a.  Create  a  random  population  of  size  N. 

b .  Sort  the  population  in  ascending  order  of  fitness. 

c.  Repeat  until  there  are  N  +  m  members  in  all: 

1 .  Choose  randomly  a  member  C  .  where  1  £  i  <  N 
(uniform  distribution).  C  is  almost  unbiased. 

2 .  Choose  randomly  a  member  Cj,  where  i  <  y  £N 
(uniform  distribution).  C.  is  biased  toward  more 
fit  members. 

3.  Choose  randomly  a  genetic  operator  gk  (see 
below). 

4.  Create  a  new  member  C  4—gk(C j.Cj)  or  C 
4—ghfCj)  if  gk  uses  only  one  member.  Discard 
C  if  it  is  the  same  as  either  parent. 

5 .  Determine  fitness  of  C. 

d.  Merge  the  new  members  into  the  population, 
discarding  duplicates. 

e.  Remove  all  but  the  last  ( strongest )  N  members  of 
the  population. 

f.  Terminate  or  go  to  step  c. 

m  was  set  to  .20N  to  reduce  the  sorting  effort  without 
materially  delaying  entry  of  new  members  into  the  active 
population.  However,  in  a  typical  application,  deter¬ 
mining  the  fitness  of  new  members  dominates  the  compu¬ 
tational  effort 


Figure  9.  Waypoint  Turn  Algorithm  Applied  to 
Closely  Spaced  Waypoints 

4.  GENETIC  ALGORITHMS 

The  traditional  optimization  procedures  are  calculus-based 
methods  (solve  for  locations  where  the  gradient  vanishes, 
or  hill  climbing:  move  in  the  direction  of  the  local 
gradient),  random  searches  (generate  points  in  parameter 
space  at  random  and  keep  the  best),  and  enumeration 
(generate  all  possible  points  and  keep  the  best).  Calculus- 
based  methods  can  be  applied  only  to  differentiable 
objective  functions,  can  be  unstable,  and  are  susceptible  to 
the  foothill  problem  —  getting  trapped  at  a  local  optimum. 
The  random  and  enumerative  methods  can  be  hopelessly 
inefficient  when  the  search  space  is  large. 

A  genetic  algorithm  (GA)  is  an  alternative  optimization 
procedure  inspired  by  Darwinian  evolution.  A  conven¬ 
tional  GA  uses  a  bit  string  which  encodes  the  problem 
parameters.  The  GA  keeps  a  population  of  -100  such 
strings  and  applies  genetic  operators  to  them  to  generate 
new  strings.  Each  new  string  is  evaluated,  and  better 
strings  are  preferentially  retained  for  the  next  generation. 


The  most  important  genetic  operator  is  crossover,  shown 
in  figure  10.  This  operator  chooses  two  positions  along 
the  bit  string  and  uses  the  enclosed  fragment  from  one 
parent  and  the  end  fragments  from  the  other  parent  Less 
important  is  mutation,  which  reverses  one  or  more  bits 
chosen  at  random  from  the  single  parent  shown  in  figure 
11. 


Parents 


Child 


Two  crossing  points  are 
selected  at  random 


Figure  10.  Crossover  Operator 


A  fraction  p  of  the  bits  are 
selected  at  random  to  be  flipped 
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Figure  11.  Mutation  Operator 


Figure  13.  10th  Generation 


The  probabilities  with  which  different  genetic  operators  are 
chosen  are  themselves  adjusted  during  the  computation. 
Details  are  discussed  in  appendix  B. 

4.2  Example 

Suppose  the  problem  is  to  find  the  value  of  x  which 
maximizes 

fn(x)  =  e~*'B2^^  sin4(5.1ffr  +  0.5) 

for  the  range  0  S  x  £  1.  a  problem  suggested  by  Goldberg 
and  Deb  (151. 


In  this  case,  the  bit  string  has  a  single  field  of  16  bits.  Let 
these  bits  be  the  Gray  code  for  the  integer  i.  (The  Gray  code 
is  used  instead  of  the  usual  binary  code  so  that  codes  for 
neighboring  values  will  differ  by  only  one  bit.)  x  is  then 
simply  i 165536. 

Crossover  and  mutation  are  the  only  genetic  operators  used. 

An  initial  random  population  of  60  mem  ben  is  shown  in 
figure  12.  By  the  10th  generation,  shown  in  figure  13. 
members  are  clustering  around  the  local  peaks  of  die  fitness 
function.  By  the  30th  generation,  shown  in  figure  14,  all 
members  are  clustered  around  the  highest  peak. 


Figure  12.  Initial  Population 


Figure  14.  30th  Generation 

4J  Application  to  Routing 
For  the  routing  problem,  a  4-bit  field  is  used  to  select 
among  16  routing  patterns  that  governed  the  heuristic 
solution  of  the  traveling  salesman  problem.  The  patterns 
comprise  the  Sierpinaki  curve,  the  Hilbert  curve,  and  14 
versions  of  the  strips  heuristic  with  different  numbers  and 
orientations  of  strips. 

The  remainder  of  the  bit  string  consists  of  one  bit  per 
potential  site,  which  is  set  if  the  site  is  to  be  visited  and 
zero  otherwise. 

The  "raw"  fitness  function  is  the  sum  of  the  values  of  the 
visited  sites.  The  constraint  on  flight  path  length  is 
handled  by  adding  a  penally  function  as  suggested  by 
Goldberg  [14],  Members  satisfying  the  constraint  are  said 
to  be  feasible.  Details  are  discussed  in  appendix  C. 

Two  genetic  operators  are  used  in  addition  to  the  crossover 
and  mutation  operators  described  above. 

The  mutate-routing  operator,  shown  in  figure  15.  replaces 
the  routing  pattern  with  another  chosen  at  random.  The 
primary  motivation  for  this  is  that  changing  the  routing 
pattern  and  changing  the  visited  sites  are  significantly 
different  operations,  perhaps  best  applied  at  different  rales. 
Defining  separate  mutation  operators  allows  the  operator 
probabilities  to  adapt  independently  (see  appendix  B). 
Early  in  the  calculation  we  would  expect  that  changes  in  the 
routing  pattern  might  well  reduce  the  search  route  length, 
so  that  the  probability  of  selecting  the  mutate-routing 
operator  should  be  moderate.  Late  in  the  calculation  we 
would  expect  that  for  a  given  member,  the  routing  pattern 
and  the  set  of  sites  to  be  visited  would  be  tuned  so  one 
another.  A  change  in  routing  pattern  would  be  unlikely  to 
decrease  the  search  route  length.  However,  site  changes 
might  still  improve  the  search  (by  removing  a  site  to 
shorten  the  path  length  or  adding  a  site  to  increase  the 


weight).  Therefore  it  would  be  reasonable  to  mutate  sites 
more  often  than  routing  patterns. 

One  field  is  filled 
with  random  bits 


Figure  15.  Mutate-Routing  Operator 

The  other  operator  wu  motivated  by  the  observation  that 
the  algorithm  frequently  chose  routes  that  visited  relatively 
low  weight  sites  while  skipping  nearby  sites  with  higher 
weights.  This  appeared  to  be  due  to  the  turn  radius 
limitation.  Merely  adding  the  higher  weight  site  may  lead 
to  the  addition  of  a  loop,  whose  length  makes  the  path 
infeasible.  On  the  other  hand,  deleting  the  low  weight  site 
reduces  the  value  of  the  path.  Thus  moving  the  visit  to  the 
higher  weight  site  would  require  two  mutations  (deleting 
one  site  and  adding  the  other)  but  the  intermediate  states 
have  low  value  and  would  be  unlikely  to  survive.  In  GA 
terminology,  the  problem  is  deceptive. 

The  deception  is  overcome  by  combining  the  two 
mutations  to  form  the  move-bit  operator.  This  operator, 
shown  in  figure  16,  chooses  a  visited  site  at  random  and 
clears  the  corresponding  bit  in  the  bit  string.  It  then  finds 
the  preceding  and  following  set  bit  in  the  string  and  sets 
some  different  bit  in  the  interval  between  them.  This 
procedure  makes  sense  only  because  the  sites  are  rearranged 
in  a  preprocessing  step  so  that  neighboring  bits  represent 
nearby  sites.  (Actually,  the  sites  are  put  into  Sierpinski 
curve  order.) 


One  bit  is  selected  at  random 


Figure  16.  Move-Bit  Operator 

The  progress  of  the  calculation  may  be  shown  by  plotting 
the  raw  fitness  (sum  of  values  of  visited  sites)  of  the  best 
feasible  member  in  each  generation.  Typical  plots  are 
shown  in  figure  17.  The  fimess  increases  rapidly  at  first, 
then  more  slowly.  (The  algorithm  makes  about  80  percent 
of  it*  progress  toward  the  fatal  value  in  the  first  20  percent 
of  the  time  -  a  value  which  doesn't  change  much  with 
different  run  timea.) 
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birth 


Figure  17.  Score  of  Best  Member 

One  of  the  important  tuning  parameters  is  the  population 
size.  Populations  of  up  to  several  hundred  members  were 
used.  Generally,  large  populations  take  longer  to  converge 
but  reach  better  solutions.  However,  results  are  also  poorer 
for  very  large  populations  when  the  total  number  of 
evaluations  is  held  fixed.  This  is  due  to  the  tradeoff 
between  population  variability  (i.e.,  presence  of  the 
building  blocks  for  good  solutions)  and  the  number  of 
generations. 

If  the  population  is  too  small,  the  member*  won't 
adequately  span  the  search  space.  If  the  population  is  loo 
large,  then  (for  a  fixed  number  of  evaluations)  not  enough 
generations  will  past  to  allow  the  best  features  of  the 
various  members  to  be  combined.  This  is  shown  by  the 
results  for  a  20  site  problem  shown  in  figure  18.  Four  runt 
were  made  for  each  population  size,  with  each  limited  to 
4000  evaluations.  The  figure  shows  the  mean  score  and  a 
one  standard  deviation  range.  The  optimum  population  in 
this  case  is  apparently  near  ISO  members.  The  results  for  a 
SO  site  problem  shown  in  figure  19  suggest  that  the 
optimum  population  may  increase  for  larger  problem*. 


population 


Flguro  18.  Scores  as  a  Function  of 
Population  for  20  Sits  Problsm 


60  80  100  120  140  160  160  200  220  240  260  280  300 
population 

Figure  10.  Scores  as  a  Function  of 
Population  for  50  Sits  Problem 

5.  RESULTS 

Figure  20  shows  a  sample  problem  with  20  sites.  The  path 
is  required  to  start  at  the  point  labeled  1  and  end  at  the  point 
labeled  2.  The  other  sites  are  shown  as  circles  with  areas 
proportional  to  their  weight  (that  is,  the  expected  likeli¬ 
hood  of  finding  the  target  there). 
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Figure  20.  Sample  Problem  with  20  Sltss 


Figure  21  shows  the  best  path  found  through  those  sites 
with  path  length  restricted  to  3. 


Figure  21.  Sample  Path  Through  12  of  20 
Sites 

Figure  22  shows  a  second  sample  problem  with  30  sites. 
The  variation  among  paths  found  by  the  genetic  algorithm 
can  be  judged  from  figures  23-23,  which  show  the  three  best 
paths  with  length  less  than  3. 
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Figure  22.  Sample  Problem  with  50  Sites 


Figure  23.  Path  Through  20  of  50  Sites 
(Length  4.91,  Weight  27.23) 


Figure  24.  Path  Through  19  of  50  Sites 
(Length  4.94,  Weight  26.55) 


Figure  25.  Path  Through  19  of  50  Sites 
(Length  4.99,  Weight  26.31) 
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None  of  the  above  runs  used  the  arbitrary  insertion  routing 
-  procedure,  relying  instead  on  spacefilling  curves  and  strips 
routing  patterns.  Detailed  results  and  genetic  algorithm 
parameters  are  listed  in  table  1. 


Table  1.  Parameters  for  Sample  Results 


Citias  Visit  ad 

Weight 

Length  Population 

Eval. 

Figure 

20 

12 

11.14 

2.78 

120 

4000 

21 

50 

20 

27.23 

4.91 

200 

3000 

23 

50 

19 

26.56 

4.94 

200 

3000 

24 

50 

19 

26.31 

4.99 

200 

3000 

25 

6.  DISCUSSION 

A  method  has  been  developed  for  generating  search  routes 
for  strategic  bombers.  With  certain  simplifying 
assumptions,  the  routing  problem  can  be  modeled  as  a 
covering  salesman  problem,  for  which  we  have  found 
efficient  new  heuristics  based  on  spacefilling  curves.  The 
result  is  a  two-dimensional  route  which  passes  within  a 
specified  distance  of  all  the  sites  of  interest,  while 
approximately  minimizing  the  total  distance  traveled. 

This  procedure  has  been  extended  to  include  the  selection  of 
an  appropriate  subset  of  sites  when  their  number  is  large, 
so  that  time  and  fuel  constraints  preclude  visiting  all  of 
them.  The  finite  turn  radius  is  also  taken  into  account 

Problems  with  both  finite  sensor  range  and  large  numbers 
of  sites  have  not  been  treated  here,  but  only  for  simplicity. 
Applying  both  methods  simultaneously  would  require  no 
essential  changes. 

A  bigger  effort  would  be  needed  to  permit  revisits  of  sites, 
and  to  properly  accumulate  credit  for  multiple  visits. 
Neither  the  spacefilling  curve  heuristic  nor  the  strips 
heuristic  easily  allows  multiple  visits.  The  arbitrary 
insertion  heuristic  could  accommodate  a  starting  route  with 
multiple  visits,  and  could  be  adapted  to  generate  such  a 
route  as  well. 

This  work  still  disregards  defenses,  terrain  avoidance,  area 
searches,  waypoint  offset  (so  the  aircraft  does  not  pass 
directly  over  a  site),  and  sensor  pointing. 

Much  of  the  computational  effort  of  this  procedure  is  in 
accounting  for  the  finite  turn  radius  of  the  aircraft.  It  might 
be  improved  by  first  calculating  a  lower  bound  (the  length 
of  the  piecewise  straight  line  path)  and  discarding  the  path 
if  it  is  far  from  feasible. 
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A.  SPACEFILLING  CURVE  HEURISTICS  FOR 
THE  CSP 

Platzman  and  Bartholdi's  generic  spacefilling  heuristic 
suggests  the  following  procedure  for  the  Euclidean  covering 
salesman  problem:  find  a  heuristic  tour  through  all  the 
cities,  then  choose  a  subset  of  cities  that  will  cover  all  the 
cities.  (Note  that  solving  the  routing  problem  first  and  the 
covering  problem  second  is  just  the  opposite  of 
COVTOUR.) 

A.l  Basic  Algorithms 

We  have  developed  a  family  of  heuristics,  with  different 
methods  of  selecting  the  subset  of  cities  to  be  visited.  The 
simplest  such  procedure  is  as  follows: 

HEURISTIC  CSP-2 

a.  Use  a  spacefilling  curve  heuristic  to  find  a  tour 
through  all  the  points.  Denote  the  sorted  points  by 
p  ...  p  ,  with  corresponding  keys  &\-.0n. 

b.  Let  s« — 1. 

c.  Find  the  last  point  p j  e  p.  -p n  for  which 

2 ijD^Oj.Sj)  S  d.  Mark  pj  <pj  is  the  last  point 
that  covers  p(j 

d.  Find  the  first  point  p  k  €  Pj+y  ~Pn  for  which 

2^D^0j,0g)  >  d.  If  there  is  no  such  pk,  go  to  f. 
Otherwise, 

e.  Let  i*-k  (pi  is  the  first  point  not  covered  by  pj)  and 
go  to  c. 

f.  Visit  the  marked  points  in  subscript  order,  then 
return  to  (he  first  marked  point. 

Given  the  nearness  property  (8),  the  tests  in  steps  c.  and  d. 
guarantee  that  every  city  is  covered.  However,  these  tests 
are  conservative  by  about  a  factor  of  two.  Somewhat 
shorter  tours  can  be  found  by  replacing  the  test 

W*)  >  *  in  step  d.  with  I pj  •  pk I  >  d,  to  test  the 

Euclidean  distance  directly.  We  will  refer  to  the  resulting 
heuristic  as  CSP-3.  CSP-2  and  CSP-3  require  0(n  log  n) 
time. 

If  we  made  the  same  replacement  in  step  c,  we  would  know 
that  each  city  in  pi-p)  could  be  covered  by  a  visit  to  p-,  but 
would  not  have  tested  their  distances  to  pj  which  is  being 
visited.  For  i  <  i'  <  j,  even  if 

| p  -t  ~Pj  j  £  d  and  Jpj  '  -pj  j  Z  d,  it  is  not  necessarily 
true  that  \p- -p  j  |  Z  d  .  However,  the  last  city  Pj  which 


covers  each  city  ri  and  the  intermediate  cities,  can  be 
efficiently  found  in  a  preliminary  pass  starting  with  the  last 
point. 

HEURISTIC  C  SP4 

a.  Use  a  spacefilling  curve  heuristic  to  find  a  tour 
through  all  the  points.  Denote  the  sorted  points  by 

P\—Ph>  wirA  corresponding  keys  &i~0n. 

b.  Let  j*—n  and  i*-n. 

c.  Let  ti*-j  <Pj  is  the  last  point  that  covers  pt), 

d.  If  i~0  goto  h.  Otherwise, 

e.  //|p(-  -pj  j  Z  d,  go  to  c.  Otherwise, 

f.  Let  jt-j-l. 

g.  I^p-p  j  |  >  d,  for  some  point p  e  p^-p j,  go  to 

f.  Otherwise,  go  to  c. 

h.  Let  ie — 1. 

i.  Let  j*-ti.  Mark  Pj. 

j.  Find  the  first  point pk  €  Pj+y~.pn  for  which 

\p  j  -pk  j  >  d.  If  there  is  no  such  pk,  go  to  t. 
Otherwise, 

k.  Let  i*-k  <pi  is  the  first  point  not  covered  by  Pj)  and 
go  to  i. 

l.  Visit  the  marked  points  in  subscript  order,  then 
return  to  the  first  marked  point. 

If  no  one  city  covtrs  more  than  m  other  cities,  the 
preliminary  pass  (steps  b.  -  g.  )  requires  0{n  m)  time.  This 
may  dominate  the  0(n  log  n)  cost  of  the  sort  in  step  a. 

A.2  Extension  to  Unequal  Covering  Distances 
The  formulation  of  the  CSP  in  [1]  permits  the  covering 
distance  to  be  different  for  each  city.  For  example,  when 
routing  a  rural  health  care  delivery  team,  one  might  imagine 
that  the  covering  distance  is  a  function  of  the  public 
transportation  system  at  each  stop.  CSP-4  will  still  work  if 
d  is  replaced  by  d;.  However,  CSP-2  and  CSP-3  must  be 
modified. 

Note,  for  example,  that  if  i  <  j  <  /.  we  know 

2 ^D(Oj,0j)  Z  2^D^0;,0j'J.  Therefore,  in  step  c.  of  CSP- 
2,  it  is  sufficient  to  scan  forward  to  the  first  city 

pj  e  pi+i~pn  lor  which  2 ^D^0{,0jj  >  d,  then  back  up 

by  one.  With  varying  covering  distances,  this  procedure 
will  not  necessarily  find  the  last  city  that  covers  p,.  As 
before,  we  can  make  a  preliminary  pass  to  identify  for  each 
city  the  last  city  that  coven  it.  The  revised  procedure  is: 

HEURISTIC  CSP-5 

a.  Use  a  spacefilling  curve  heuristic  to  find  a  tour 
through  all  the  points.  Denote  the  sorted  points  by 

Pi  —  Pm'  corresponding  keys  0\  ~0n. 
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b.  Let  j*-n  and  i*~n. 

c.  lf2^D(9i.0j)>dj,  go  to  f. 

d.  Let  n*-  j  (pj  is  the  last  point  that  covers  pj. 

e.  If  i  >  1  let  and  go  to  c.  Otherwise,  go  to  g. 

/.  /fj  >  1  let  /«-  j-l  a.td  go  to  c.  Otherwise, 

g.  Let  Mark  p.. 

h.  Find  the  first  point p^  e  Pj+\—Pn  for  wbich 

| p  j  ~P g  j  >  d  j  .  If  there  is  no  such  pk,  go  to  j. 
Otherwise, 

i .  Let  it-k  (p,  is  the  first  point  not  covered  by  pj)  and 
go  to  g. 

j.  Visit  the  marked  points  in  subscript  order,  then 
return  to  the  first  marked  point. 

In  this  case  the  preliminary  pass  takes  only  O(n)  time 
because  it  is  not  necessary  to  test  the  intermediate  cities,  so 
the  entire  procedure  still  takes  only  0(n  log  n)  time. 

A3  Heuristic  Performance 

The  expected  length  of  the  optimum  tour  through  n  points 
uniformly  distributed  in  the  unit  square  is 

P*  4n  where  0.765  <,  P*  <,  0.765  +  4 In  as  shown  by 
Beard  wood  et  al.  [16].  The  tours  generated  by  TSP-1  are 

asymptotically  bounded  above  by  P'fn. ,  where 

PlP*  =  1.25,.  and  the  enhancement  in  TSP-2  improves 
this  ratio  to  1.15  [3]. 

Platzman  and  Bartholdi  [17]  proved  that  their  heuristic 
yields  a  tour  within  a  factor  Of  log  n)  of  the  optimum 
length.  Bertsimas  and  Grigni  [18]  have  demonstrated  that 
the  ratio  can  in  fact  be  as  large  as  Of  log  n)  for  points 
arranged  along  a  line.  This  is  also  a  lower  bound  on  the 
worst  case  performance  of  the  heuristics  proposed  here. 

To  determine  empirically  the  effectiveness  of  the  different 
methods,  six  combined  heuristics  (TSP-1  and  TSP-2  with 
CSP-2  through  CSP-4)  were  used  to  solve  the  same  set  of 
100  CSPs,  each  with  100  cities  distributed  randomly  in  the 
unit  square  and  a  constant  covering  distance  of  0.1.  (CSP-5 
is  not  included  because  it  will  generate  the  same  tours  as 
CSP-3,  if  the  covering  distances  are  all  equal  and  the  keys 
are  unique.)  In  each  case,  Sierpinski's  curve  and  Platzman 
and  Bartholdi's  0(n  log  n)  implementation  of  the 
improvement  procedure  were  used.  The  resulting  tour 
lengths  are  shown  in  the  first  two  rows  of  table  2.  Entries 
indicate  the  mean  ±  one  standard  deviation.  The  benefits  of 
the  tour  improvement  procedure  apparently  carry  over  to 
the  resulting  CSP  tours. 

Table  2.  Heuristic  Tour  Lengths  for  100  City 
CSPs 

Improve.  Aft. 

TSP  CSP _ USE _ CSP-2  CSP-3  CSP-4 

no  no  9.62±0.38  9.0010.41  7.8510.48  7.1710.45 

yes  no  8.8210.31  8.2410.34  7.3110.37  6.7310.38 

no  yes  9.6210.38  8.2010.33  7.1010.36  6.5810.36 

yes  yes  8.8210.31  7.9710.33  6.9310.34  6.3810.35 


The  same  improvement  procedure  can  also  be  applied  after 
selecting  the  cities  to  be  visited.  The  results  are  shown  in 
the  last  two  rows  of  table  2.  As  shown  in  the  third  row  of 
the  table,  applying  the  procedure  once,  either  before  or 
after  selecting  the  cities,  results  in  about  the  same  final  tour 
length.  However,  applying  the  procedure  before  selecting 
the  cities  reduces  the  number  of  cities  in  the  final  lour.  The 
best  tours  are  produced  by  applying  the  improvement 
procedure  both  before  and  after  selecting  the  cities.  (It  can 
make  a  further  improvement  because,  with  fewer  cities 
present,  it  will  consider  larger  perturbations.)  For  the 
results  reported  below,  the  improvement  procedure  was 
applied  only  to  the  initial  TSP  tour. 

To  determine  empirically  the  performance  of  the  heuristics 
as  a  function  of  problem  size,  TSP-2  combined  with  CSP-2 
through  CSP-4  were  applied  to  CSPs  of  from  20  to  1,000 
cities  distributed  randomly  on  the  unit  square,  with  a 
constant  covering  distance  of  0.1.  The  resulting  tour 
lengths  are  shown  in  figure  26.  Each  data  point  is  an 
average  of  SO  different  CSPs. 
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Figure  26.  CSP  Tour  Lengths  with  Covering 
Distance  d  *  0.1 

Performance  statistics  for  TSP-2  are  shown  in  the  first  three 
columns  of  table  3.  For  TSPs  of  1,000  cities,  it  generated 
tours  of  mean  length  2756  =  0.872 Vl  000.  For  a  tour  of 
length  0.872-Jn,  the  average  distance  between  successive 
cities  along  the  tour  is  0.872/-fn.  For  a  constant  covering 
distance  of  d,  we  would  expect  the  routing  part  of  a  CSP  to 
dominate  when  d  <  0.872i*fn.  For  larger  n,  the  set  covering 
part  of  the  problem  would  dominate.  For  d  =  0.1  the 
boundary  between  the  two  regions  would  be  at 

nf,  =  (0.872/0.1)^  =  76.  This  effect  is  clearly  evident  in 
figure  26. 

TSP-2  combined  with  CSP-2  through  CSP-5  were  then 
applied  to  the  same  set  of  CSPs,  but  with  covering 
distances  chosen  uniformly  from  the  interval  [0,0.1].  The 
resulting  tour  lengths  are  shown  in  figure  27.  For  this  case, 

the  mean  covering  distance  is  d  =  0.05.,  so  the  boundary 
between  the  routing-  and  set  covering-dominated  regions  is 

at  approximately  n f,  =  (0.872 Id)  =  304. 
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Table  3.  Performance  of  Different  Heuristics 


TSP 

CSP 

CITIES 

VISITED 

TOUR 

LENGTH 

CPU  TIME 

d 

METHOD 

CITIES 

VISITED 

TOUR 

LENGTH 

CPU  TIME 

20 

4.13±0.39 

0.09 

0.1 

16.1411.55 

3.9910.40 

0.002 

50 

6.32±0.35 

0.24 

0.1 

CSP-3 

31.52±2.34 

5.8010.38 

0.006 

100 

8.8110.30 

0.50 

0.1 

CSP-3 

47.0413.19 

7.3510.38 

0.007 

200 

12.3710.32 

1.03 

0.1 

CSP-3 

64.1213.36 

8.9510.45 

0.020 

500 

19.5510.36 

2.66 

0.1 

CSP-3 

85.4813.63 

10.6410.44 

'  .044 

1000 

27.5610.27 

5.44 

0.1 

CSP-3 

95.8813.68 

1 1.1910.44 

0.093 

20 

4.1310.39 

0.09 

0.1 

CSP-4 

15.8411.60 

3.9910.40 

0.004 

50 

6.3210.35 

0.24 

0.1 

CSP-4 

28.8212.23 

5.5910.36 

0.012 

100 

8.8110.30 

0.50 

0.1 

CSP-4 

39.6212.78 

6.7210.37 

0.018 

200 

12.3710.32 

1.03 

0.1 

CSP-4 

48.1013.27 

7.4610.47 

0.043 

500 

19.5510.36 

2.66 

0.1 

CSP-4 

57.7012.30 

7.7410.34 

0.118 

1000 

27.5610.27 

5.45 

0.1 

CSP-4 

62.8611.71 

7.7210.27 

0.275 

20 

4.1310.39 

0.09 

[0,0.1] 

CSP-5 

18.2611.24 

4.1010.38 

0.002 

50 

6.3210.35 

0.25 

[0,0.1] 

CSP-5 

40.2412.63 

6.1210.33 

0.006 

100 

8.8110.30 

0.51 

[0.0.1] 

CSP-5 

68.9614.11 

8.1310.33 

0.012 

200 

12.3710.32 

1.05 

[0,0.1] 

CSP-5 

105.2215.73 

1 0.4410.39 

0.024 

500 

19.5510.36 

2.70 

[0,0.1] 

CSP-5 

159.5619.38 

13.6310.58 

0.059 

1000 

27.5610.27 

5.54 

[0,0.1] 

CSP-5 

178.6819.46 

15.0710.55 

0.117 

20 

4.1310.39 

0.09 

[0,0.1] 

CSP-4 

17.8011.28 

4.0810.39 

0.003 

50 

6.3210.35 

0.25 

[0,0.1] 

CSP-4 

37.2612.91 

6.0310.36 

0.007 

100 

8.8110.30 

0.51 

[0.0.1] 

CSP-4 

59.1013.62 

7.7510.34 

0.014 

200 

12.3710.32 

1.05 

[0,0.1] 

CSP-4 

81.6415.90 

9.5410.51 

0.030 

500 

19.5510.36 

2.70 

[0,0.1] 

CSP-4 

101.7615.62 

11.0610.45 

0.083 

1000 

27.5610.27 

5.54 

[0-0-11 

CSP-4 

103.3816.29 

10.9810.47 

0.185 

These  heuristics  for  the  CSP  have  disregarded  the  fact  that 
both  the  tour  and  the  spacefilling  curve  f  are  closed. 
Suppose  a  lour  includes  p2  which  covers  pt  and  ps  and  pm, 
which  covers  no  other  cities.  By  the  nearness  property  (8) 
we  expect  p.  to  be  close  to  p;.  If  p2  also  happened  to  cover 
pm,  the  tour  could  be  shortened  by  omitting  px. 

For  n  »  nb,  very  little  benefit  was  found  in  using  TSP-2 
rather  than  TSP-1  .  Apparently,  most  of  the  local  changes 
made  by  the  improvement  procedure  are  lost  when  covered 
cities  are  removed  from  the  tour.  An  alternate 
interpretation  is  that  the  routing  pan  of  the  problem  is 
comparatively  unimportant  in  those  cases,  and  the  primary 
benefit  of  a  spacefilling  curve  heuristic  is  to  linearize  the 
underlying  SCP.  This  leads  us  to  the  recognition  that  the 
same  heuristics  can  be  applied  to  planar  SCPs  with 
Euclidean  metrics.  The  result  would  then  be  the  set  of 
marked  points,  and  their  order  would  be  disregarded.  This 
heuristic  would  be  approximate  in  more  than  one  sense. 
Even  the  optimal  (minimum  tour  length)  solution  to  the 
CSP  would  not  necessarily  correspond  to  an  optimal  (fewest 
cities)  solution  to  the  SCP. 

B.  ADAPTIVE  OPERATOR  PROBABILITIES 
The  efficiency  of  a  genetic  algorithm  depends  on  the 
sellings  of  several  parameters  including  population  size 
and  the  probabilities  of  applying  each  genetic  operator. 
Delong  found  robust  settings  by  using  a  test  suite  of 
function  optimization  problems  (19).  Later.  Greffenstette 
used  a  genetic  algorithm  to  find  a  better  set  of  parameter 
values  (20).  However,  these  studies  used  only  the  crossover 
and  mutation  operators. 


Citlat 

Figure  27.  CSP  Tour  Lengths  with  Covering 
Distance  t^Chosen  Uniformly  from  [0,0.1] 

Performance  statistics  for  some  of  these  runs  are  shown  in 
table  3.  For  tour  lengths  and  number  of  cities  visited  in  the 
CSP  tour,  the  mean  and  one  standard  deviation  are  listed. 
The  execution  times  (in  seconds  for  an  80386-based 
personal  computer)  for  the  routing  and  the  set  covering 
parts  of  the  CSP  are  listed  separately.  CSP-4  took 
somewhat  more  time  than  CSP-5,  but  the  tune  for  TSP-2 
dominated  in  each  case,  and  the  actual  times  were 
approximately  proportional  to  n. 

A. 4  Remarks 

The  effectiveness  of  these  heuristics  is  due  to  the  fact  that 
the  spacefilling  curve  is  self  similar,  so  that  a  subsequence 
of  a  heuristic  tour  is  itself  a  heuristic  tour  (17).  This  is  not 
true  of  some  heuristic  solutions  to  the  TSP.  such  as  the 
"strips"  method  described  by  Karp  and  Steele  (6)  or  the 
nearest-neighbor  heuristic. 
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When  additional  operators  are  used,  it  is  necessary  to  set 
their  selection  probabilities.  Setting  them  by  either  of  the 
above  methods  would  require  a  very  considerable  effort.  It 
is  attractive  to  set  them  adaptively  instead. 

The  following  scheme  for  adaptively  setting  operator 
probabilities  was  presented  by  Davis  (2i).  Each  new 
individual  that  is  better  than  the  current  best  individual 
acquires  a  "local  delta"  equal  to  the  improvement.  At 
intervals  of  /  evaluations,  each  of  the  last  W  individuals 
pass  back  to  ita  parent(s)  P  times  the  sum  of  its  local  delta 
and  the  deltas  inherited  from  its  progeny  (except  that  no 
delta  is  passed  back  more  than  M  generations).  Each 
individual  then  passes  its  remaining  delta  to  the  operator 
which  created  it.  The  operators  accumulate  the  deltas  in  a 
vector  C.  The  vector  V  of  operator  probabilities  is  updated 
by  shifting  a  fraction  S,  so  that  t'<-sc/|c]+(t-s)v . 

The  five  parameters  W,  /,  S,  P,  and  M  effectively  replace  the 
operator  probabilities  as  governing  parameters.  Davis 
found  the  values  W  =  100, 1  =  SO,  S  =  0.15,  P  =  0.15,  and  M 
-  10  to  be  effective. 

There  are  two  points  that  seem  to  make  implementation  of 
this  awkward.  The  first  is  that  even  deleted  members  would 
have  to  be  kept  around,  on  the  chance  that  one  of  their 
progeny  would  pass  back  some  delta.  The  other  concerns 
the  handling  of  M,  the  limit  on  the  number  of  generations 
that  delta  is  passed  back.  If  M  could  be  disregarded,  the 
deltas  could  be  propagated  in  one  pass,  starting  with  the 
most  recent  member,  with  each  step  involving  only  the 
member's  immediate  parents.  Accounting  for  M  would  seem 
to  require  a  walk  of  the  family  tree  of  each  member  having  a 
local  delta,  to  a  depth  of  M  or  the  edge  of  the  adaptation 
window  (whichever  came  first).  This  procedure  would  seem 
to  grow  exponentially  with  W/population.  and  would  be 
particularly  lengthy  if  two-parent  operators  were  successful 
(leading  to  large  family  trees). 

In  addition,  one  might  want  to  reward  operators  when  they 
created  individuals  that  were  better  than  any  of  their 
parents,  regardless  of  whether  they  were  better  than  the 
previous  best  individual.  This  would  give  the  adaptation 
mechanism  more  information  to  work  with. 

Because  of  the  above  concerns,  the  following  somewhat 
simpler  scheme  has  been  used  instead. 

Each  member  has  an  associated  "responsibility  vector"  R 
which  indicates  the  relative  roll  each  genetic  operator  had 
in  its  creation.  If  operator  gk  is  used  to  create  child  c  from  a 
single  parent  p,  the  new  member  gets  a  responsibility 
vector 

Re  =  PRp  +  (I-P)Uk  (B-l) 

where  Ukhas  a  1  in  the  4th  position  and  Os  elsewhere.  If 
the  operator  used  two  parents  m  and  /,  the  child  gets  a 
responsibility  vector 

“c-W»  +  RfV2  +  U-P)Uk  (B-2) 

The  operators  accumulate  credit  for  improvements  in  a 
vector  C.  If  the  fitness  of  the  new  member  exceeds  that  of 

its  better  parent  by  t,  C  is  incremented  by  If  the 

new  member  is  less  fit  than  at  least  one  parent,  C  is  not 
changed.  Each  generation  (m  births),  the  vector  V  of 
operator  probabilities  is  updated  by  shifting  a  fraction  5: 


V'«-SC/|q+(l-S)V'  (B-3) 

and  the  credit  vector  is  attenuated: 

C*-pC  (B-4) 

For  this  work,  P  =  0.90,  S  =  030ml  100.  and  m  =  050. 

This  scheme  follows  the  two  principles  suggested  by 
Davis,  namely  that  the  probability  of  applying  an  operator 
should  be  altered  in  proportion  to  the  performance  of  the 
individuals  it  creates,  and  that  local  measures  of 
performance  are  insufficient  (that  is,  operators  creating 
ancestors  of  successful  individuals  should  also  be  rewarded). 

An  example  of  operator  probability  adaptation  is  shown  in 
figure  28.  Each  curve  is  an  average  over  four  runs.  The 
adaptive  procedure  confirms  the  importance  of  the 
crossover  operator,  since  its  probability  steadily  increases. 
On  the  other  hand,  it  suggests  the  "move-bit"  operator  may 
be  relatively  unhelpful  (or  perhaps  helpful  only  early  in  the 
optimization  process). 


birth 

Figure  28.  Operator  Probability  Adaptation 

C.  CONSTRAINED  OPTIMIZATION 

Suppose  we  wish  to  use  a  genetic  algorithm  to  minimize  the 

function 

fix)  (C-I) 

while  satisfying  the  constraint 

g(x)  <  0  (C-2) 

Goldberg  suggests  a  penalty  function  approach  so  that  the 
objective  function  is  replaced  by  a  compound  objective 
function: 

f(x)  =  f(x)  +  od>(r)  (C-3) 

where  r  =  g(x),  a  is  a  nonnegative  penally  coefficient  and 
$  is  a  nonnegative  penalty  function  1)4). 

Richardson,  el  al„  found  that  a  penalty  function  should  not 
be  too  harsh  because  the  most  direct  path  from  a  given 
solution  to  the  optimal  solution  may  require  some 
infeasible  intermediate  structures  (22).  That  is,  the  penalty 
function  should  be  chosen  to  balance  the  preservation  of 
information  against  the  pressure  for  feasibility. 
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It  is  necessary  to  penalize  infeasible  members,  but  not  so 
much  that  moderately  infeasible  members  cannot  contribute 
information.  It  is  helpful  to  reward  moderately  feasible 
members  for  satisfying  the  constraint  well.  The  penalized 
fitness  function  should  have  a  maximum  at  the  feasibility 
boundary  (where  g(x)  =  0).  Thus,  we  want  a  penalty 
function  which  is  smooth  at  0  and  has  a  slope  there  equal  to 
fig ’.  On  the  other  hand,  members  well  inside  the 
feasibility  boundary  should  be  neither  penalized  no. 
rewarded,  so  the  penalty  function  should  be  zero  for  large 
negative  values.  Members  well  outside  the  feasibility 
boundary  should  be  heavily  penalized,  so  the  penalty 
function  should  be  large  for  large  positive  values. 


One  effective  penalty  function  is 

=  ze*tw  (C-4) 


which  is  shown  with  a  solid  line  in  figure  29. 


g( *,)  <  g<*j)-  (C-7) 

If  a  is  too  large  the  optimal  solution  may  be  precluded,  and 
if  a  is  too  small  then  members  will  tend  to  be  infeasible.  It 
is  therefore  important  that  a  be  close  to  fig'.  This  ratio  is 
estimated  from  the  current  population  (specifically,  from 
dominant  members  on  either  side  of  the  feasibility 
boundary)  using  a  single  state  Kalman  filter  as  follows: 

DERIVATIVE  ESTIMATE 

a.  Sort  the  members  on  their  constraint  values. 

b.  Find  a  fit  member  near  the  feasibility  border  (the 
most  fit  member  xjwith  constraint  - 1  <  g(if)  <  0) 

c.  Find  an  infeasible  member  near  the  feasibility 
border  (the  most  fit  member  x,  with  constraint  0  < 
g(*i)  <  l  )■ 

d.  If  the  moderately  infeasible  member  was  more  fit 
(that  is.  fixj  <  f(Xj)),  the  derivative  fig'  is 
estimated  as  <*'  =  (flxi)-f(x/))l(g(xi)-g(x^).  The 
filtered  derivative  estimate  is  updated  according  to 
a*-tPa'*Ra)HP*R) ,  and  its  estimated  covariance  P 
is  updated  according  to  Pt-RPl(R*P)+Q 

e.  Otherwise,  p*-p*q 

Q,  R,  and  P  are  initialized  in  the  ratio  1:10:1011.  so  the 
Kalman  filter  gain  P/(P+R)  is  very  high  on  the  first 
iteration,  drops  quickly  thereafter,  and  doesn’t  rise  again 
unless  there  are  several  generations  in  a  row  with  no 
improvements. 

For  some  runs,  the  width  w  was  kept  constant  at  2. 
However,  there  was  some  evidence  that  decreasing  w  made 
the  accurate  determination  of  a  less  critical.  This  was  done 
by  initially  setting  w  to  1.  and  thereafter  to  the  range  of  the 
constraint  function  for  the  current  population: 


Figure  28.  Penalty  Functions 
A  simpler  alternative  which  works  almost  as  well  is 


r  -z  . 

max  min 


(C-8) 


z 


for  z  S  0 


(C-5) 


forz  >  0 


which  is  shown  with  a  dotted  line  in  figure  29.  Each 
function  has  a  unit  slope  at  z=0,  so  the  compound  objective 
function  will  have  a  local  minimum  at  the  feasibility 
boundary  if  a  then  plays  the  role  of  a  Lagrange 

multiplier.  Each  function  also  has  a  second  parameter  w,  a 
characteristic  width,  which  is  discussed  below. 


Siedlecki  and  Sklansky  introduced  the  concept  of 
dominance  (23).  Recall  that  we  have  assumed  a 
minimization  problem,  so  that  better  solutions  correspond 
to  smaller  values  of  /.  Solution  xi  dominates  solution  x-  if 
fjxj  <  fjx-)  for  any  positive  value  of  a .  Evidently,  this 


implies  both 


and 


ff*i)  <  flXj) 


(C-6) 
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A  method  for  planning  paths  through  a  digital 
map  is  presented.  The  task  consists  of  planning 
3-dimensional  paths  for  autonomous  air  vehicles 
over  a  terrain  represented  by  a  digital  map  with 
different  strategies  and  constraints.  Possible 
strategies  minimize  time,  danger,  or  fuel  con¬ 
sumption.  Constraints  are  lateral  and  vertical 
maximum  accelerations  as  well  as  time  and  fuel 
constraints. 

The  path  planning  problem  can  be  viewed  as  a 
shortest  path  problem  (geodesic  problem)  in  a 
space  with  a  non-Eucl tdean  metric  depending  on 
the  applied  strategy.  One  has  to  minimize  a  cost 
functional  giving  '•ise  to  the  Kami 1 ton- Jakobi 
equation  which  is  solved  by  Dynamic  Programming 
techniques.  Because  of  the  digitization  bias,  a 
second  optimization  step  consisting  of  direct 
optimization  methods  is  sometimes  necessary.  The 
result  is  a  fast,  non-heuristic  and  flexible 
technique  for  strategic  route  planning. 


1  Introduction 

One  fundamental  problem  for  an  autonomous 
vehicle  or  aircraft  is  to  plan  a  path  from  an 
initial  state  to  the  final  state  of  the  vehicle 
In  or  over  a  kn  .1  terrain.  The  state  of  the 
robot  consists  .  .  general  of  positon,  orienta¬ 
tion.  time,  speeci  stc.  A  survey  of  recent 
developments  In  this  field  is  given  by  Mitchell 
(Ref  1)  with  helpful  references. 

In  this  paper  terrain  (represented  by  a  digital 
map)  is  either  a  superposition  of  natural  envi¬ 
ronment  with  artificial  obstacles  and  forbidden 
regions  or  a  'danger  map’  derived  from  a  digital 
terrain  map. 

The  planning  task  takes  place  under  certain 
strategies,  for  example  minimization  of  mission 
duration  or  of  fuel  consumption,  minimization  of 
threat,  or  combinations  of  such  strategies. 
Additionally,  constraints  like  lateral  and 
vertical  maximum  accelerations  and  of  course 
collision  freeness  are  to  be  taken  Into  account. 

The  goal  of  this  paper  is  to  give  a  unified 
approach  to  the  path  planning  problem  mapping  It 
to  a  geodesic  problem  in  a  curved  geometric 
space.  Links  to  other  approaches  are  pointed 
out.  Furthermore  we  present  an  efficient  method 
consisting  of  several  succeslve  steps  for  the 
numerical  solution  of  the  path  planning  problem. 


2  Equations  for  path  planning  and  calculation 
methods 

One  approach  in  planning  paths  for  an  autonomous 
vehicle  through  a  map  is  to  minimize  a  cost 
function  describing  the  "costs"  along  a  path. 
Costs  sight  be  energy,  safety,  time  etc.  This 
variational  problem  is  equivalent  to  finding  the 
shortest  paths  (geodesics)  in  a  non-Euclidean 
space  with  a  metric  depending  on  the  applied 
strategy. 

The  existence  of  a  metric  means  that  the  length  . 
of  a  path  x(t)  can  be  expressed  by  the  integral 


j  ■  jds  -  j  i  i  *lk(Nj.ij)  ij  y  it  in 

a  a  1 , k=l 

where  the  g^  are  the  components  of  the  (sym¬ 
metric)  metric  tensor. 

Setting  the  first  variation  of  J  equal  to  zero, 
one  obtains  the  Euler-Lagrange  equations.  These 
second  order  differential  equations  are  not 
convenient  to  treat  boundary  value  problems  with 
given  endpoints  Instead  of  Initial  conditions. 

A  different  approach  uses  an  equation  for  S, 
defined  as  the  optimal  J.  i.e.  as  the  Integral 
of  (1)  evaluated  along  the  optimal  trajectory.  S 
Is  called  action  in  mechanics,  eikonal  in 
optics.  Here  it  has  the  meaning  of  the  geodesic 
distance.  For  S  a  non-linear  partial  differen¬ 
tial  equation  can  be  derived,  the  so-called 
Hamilton-Jacobl  (HJ)  equation  (Ref  2,3). 

In  the  case  of  x-dependent  g^,  the  expression 

under  the  integral  sign  of _ ( 1 )  is  a  homogeneous 
function  of  degree  one  in  x^.  J  does  therefore 

not  change  its  form  under  a  transformation  of 
the  parameter  t.  Using  this  relation  one  obtains 
(Ref  2) 

lA*\\  ’  1  (2) 

where  the  matrix  Ajk  Is  the  Inverse  of  matrix 
g11;  of  (1).  Equation  (2)  has  to  be  solved  with 
the  boundary  condition  S  (*goai>  *  0.  If  S  is 

known,  one  can  construct  the  optimal  paths  from 
all  points  in  state  space  to  *goaI • 


There  are  several  links  to  the  path  planning 
problem  mainly  with  an  origin  in  physics  which 
reveal  the  fundamental  structure  of  the  problem. 
Fermat's  principle  as  the  optical  analogue  can 
be  expressed  by  (1)  with  a  diagonal  metric 
tensor  g^  proportional  to  the  squared  defrac¬ 
tion  index.  A  mechanical  analogue  is  obtained 
using  the  position  dependent  kinetic  energy  as 
81  *  • 


Quantum  mechanics  h  m  0 

Schrodinger  - t 

equation 

(linear) 


Fokker  Plonck- 
equations 


In  (Ref  10)  a  diffusion  model  is  applied  to  path 
planning  (including  potential  field  methods  of 
Ref  it  and  12).  It  is  shown  in  Ref.  4  that  such 
an  approach  can  also  be  reduced  to  a  geodesic 
problem.  The  diffusion  equation  in  an  external 
potential  which  can  be  transformed  to  a  Schro¬ 
dinger  equation  is  in  the  small  diffusion  limit 
equivalent  to  a  Hamilton- Jakobl  equation  (Fig. 


mechanics,  optics 

HJ-equation 

(non-lineor) 


Geodesic  problen 


HJ— equation 


Apart  from  some  analytical  approaches  (Ref  4) 
the  most  efficient  method  for  the  treatment  of 
the  HJ-equatlon  is  Dynamic  Programming. 
Bellman's  Dynamic  Programming  technique  (Ref 
5,6)  converts  the  optimization  problem  Into  a 
problem  of  solving  a  set  of  recursive  equations 
and  is  the  first  step  of  our  solution  method. 

In  a  discrete-time  formulation  one  has 


S(x)  =  min  (  J(x,x  «  u)  ) 


L(x(k) , u(k) ) 


is  the  analogue  of  (1)  with  L  as  path  element 
ds.  Note  that  in  our  application  L  has  no 
explicit  k-dependence. 

The  n-dlmenslonal  vector  u(k)  determines  the 
propagation  of  x(k) 

x(k*l)  -  x(k)  ♦  u(k)  (4) 


Figure  1:  Relations  between  fundamental 

equations. 


u(x, k)  which  gets  k-lndependent  in  about 
2  1/2 

(*  )  iterations  (the  k- Independence  of  u  is 

max 

the  criterlua  to  stop  the  algorithm),  where  the 

x _ are  the  maximum  lengths  in  the  various 

max 

directions  of  the  planning  space. 

• 

The  direction  matrix  u  (x)  determines  all 
optimal  paths  of  the  complete  search  space  to 
one  goal  point  *goal .  which  is  characterized  by 

SfXg^j.k)  ■  0  for  all  k,  whereas  all  other  S 

have  to  be  set  to  infinity  at  the  beginning  of 
backward  iteration. 

Apart  from  the  discretization  errors,  the  final 
S(x)  would  be  sufficient  to  solve  the  varia¬ 
tional  problem.  For  the  special  case  treated 
here,  the  optimal  paths  are  perpendicular  to  the 
contours  of  constant  S,  so  that  the  gradient  of 
S  determines  the  path. 


Into  the  various  directions  of  planning  space. 

Because  of  the  approximation  to  choose  only  a 
finite  number  of  u's,  the  continuous  planning 
space  is  approximated  by  a  lattice  (typically  a 
3-d  square  lattice)  als  called  grid  graph.  Start 
and  goal  are  now  any  two  nodes  in  the  lattice. 

The  functional  equation  of  Dynamic  Programming 
can  now  be  derived  and  is  given  by 


S(x(k) , k)  =  min  j  L^x(k),u(k),kj  + 

s|x(k)*u(k) , k+1  j  | 


Expanding  the  right  hand  side  of  (S)  In  a  Taylor 
series  about  x(k)  and  executing  the  minimum 
operation  one  obtains  expressions  for  u,  which 
determine  the  HJ-equatlon  (2).  It  turns  out, 
however,  that  the  recursive  form  of  equation  (5) 
Is  easier  to  cope  with. 

As  usual  In  Dynamic  Programming  ,  the  recurrence 
relation  (S)  has  to  be  solved  backward  In  k.  The 
minimum  procedure  gives  a  direction  matrix 


3  Strategies  and  cost  functions 

For  our  planning  task  to  find  the  optimal  path 
of  a  missile  from  the  launch-point  to  a  fixed 
goal  we  introduced  strategies  like  safety, 
speed,  and  fuel  consumption  or  mixtures  of  this 
strategies. 

Flying  as  low  as  possible  is  considered  to  be  a 
measure  for  the  saftey  of  a  missile  to  avoid 
unknown  threats.  For  a  strategy  maximizing  the 
safety  and  minimizing  the  duration  of  flight  an 
appropriate  cost  function  was  assumed.  This 
function  is  given  by  the  metric  tensor 


(1  *  ^)2 


The  vertical  component  z(t)  forces  the  aircraft 
to  fly  always  near  the  surface.  The  parameter  R 
determines  the  ratio  between  speed  and  safety. 

The  terrain  V(x.y)  the  missile  has  to  pass  is  a 
superposition  of  the  natural  environment  and 
artificial  obstacles.  The  additional  contribu¬ 
tions  to  the  natural  terrain  may  be  forbidden 
regions  of  military  threats,  areas  with  higher 
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degrees  of  danger  etc.  V(x,y)  is  then  repre¬ 
sented  by  a  digital  nap  of  an  effective  terrain. 

To  solve  the  variational  problem  we  have  to  take 
into  account  some  boundary  conditions.  Using  the 
effective  terrain  we  get  the  boundary  condition 

z(t)  £  V(x( t ) , y( t ) )  (?) 

To  fulfill  this  condition  a  penalty  function  can 
be  added  to  the  g^  of  (6): 

Sjj-  o  •  e(V(x.y)  -  z ( t ) )  (8) 

The  stepfunction  8  ■  1  if  z(t)  is  below  V(x,y) 
and  0  otherwise,  a  Is  a  parameter  weighting  the 
strength  of  the  penalty. 

Other  boundary  conditions  have  to  be  introduced 
because  of  the  limitations  Imposed  by  the  flight 
dynamics  of  an  aircraft.  To  get  allowed  flight 
paths  the  following  constraints  have  to  be  taken 
into  account: 


(z(t)l  s  az 


(9) 


a^ls  the  maximum  possible  acceleration  in  the 

z-directlon.  The  minimum  horizontal  curvature  of 
the  flight  path  can  be  expressed  as  follows 

f  o  —  ^ 1/2 

I  (x(tP  +  (y(t)  t  s  axy  (10) 


wi  th  a 


xy 


representing  the  lateral  acceleration. 


The  boundary  conditions  (9)  and  (10)  can  be 
treated  with  penalty  functions  slmillar  to  (8). 
Using  a  discrete  search  space  in  the  Dynamic 
Programming  procedure  allows  another  possibility 
to  implement  the  constraints  Imposed  by  the 
flight  dynamics.  These  constraints  limit  the 
number  of  directions  u(k)  at  each  node  of  the 
discrete  space.  The  allowed  directions  are 
determined  by  the  flight  dynamics. 


These  boundary  conditions  also  restrict  the  size 
of  the  lattice.  To  exclude  Impossible  movements 
of  the  aircraft  a  minimum  distance  between 
adjacent  nodes  Is  required.  The  optimal  resolu¬ 
tion  of  the  digital  map  Is  therefore  determined 
by  this  minimum  distance. 


If  the  terrain  allows  the  missile  In  any  case  to 
follow  the  surface  V(x,y)  we  can  reduce  exactly 
the  task  of  planning  on  a  3-D  lattice  to  a 
2-dlmenslonal  search.  Therefore  In  the  case  of  a 
terrain  which  is  not  too  ragged  we  separate  the 
variational  problem  In  two  independent  steps. 

The  first  step  Is  the  search  for  the  optimal  path 
on  the  surface  V(x,y).  In  the  second  step  z(t) 

Is  calculated  along  the  path  found  In  the  prior 
step. 


This  method  of  planning  In  two  Independent  steps 
has  the  great  advantage  of  reducing  the 
calculation  effort.  However.  Its  application  Is 
limited.  Planning  in  terrains  showing  steep 
ascents  the  2-step  solution  might  fall  because 
the  aircraft  cannot  completely  follow  (because 
of  the  acceleration  constraints)  the  terrain.  In 
this  case  the  optimal  paths  have  to  be  calcu¬ 
lated  on  a  3-dlmensional  lattice. 


To  minimize  fuel  consumption  one  can  use  in  a 
first  approximation 

8lk  ”  5lk*  <“2  ♦  B‘(W)"x-e[(W)*xl)  (11) 

where  0  is  the  step  function. 

The  space  of  possible  paths  between  two  end¬ 
points  has  a  complicated  structure,  in  general 
with  many  local  minima.  If  the  search  with 
Dynamic  Programming  is  not  too  crude,  one  finds 
with  this  method  the  region  of  attraction  of  the 
global  minimum  and  has  therefore  a  convex 
minimum  problem,  which  can  be  treated  In  a 
subsequent  step  using  the  primary  solution 
delivered  by  Dynamic  Programming  as  the  Initial 
value. 

In  the  discrete  formulation  for  J  one  has  a 
normal  minimum  problem 

K 

J(x,u)  =  jM.(x(k),x(k+l)-x(k))  =  min  (12) 

for  the  »(k)  which  can  be  treated  by  first  or 
second  order  gradient  methods.  It  is  useful  to 
perform  a  Fourier  transformation  of  the  x(k) . 
Because  of  the  smoothness  of  the  flight  paths 
the  Fourier  series  can  be  limited  to  IS  terms 
maximum,  reducing  considerably  the  number  of 
variables  which  are  now  the  Fourier  coeffi¬ 
cients.  The  expected  gain  in  J  is  of  the  order 
of  a  few  percent. 


4  Extensions  and  reduction  of  calculation 
effort 

An  Important  point  is  the  reduction  of  the 
calculation  effort  by  the  constraints  in  the 
space  X(k)  of  the  admissible  x(k) 

X(k)  *  |  x(k)  lx(k)  m  x(k+l )  +  u(k+l) 

with  x(k-»l)  €  X( k*l )  and  x(k+l)  »  x(k+2)  | 

X(k)  contains  only  those  points  x(k)  which  are 
neighbours  of  points  which  have  changed  In  the 
previous  step,  or  equivalently,  only  those 
points  or  nodes  x(k+l)  have  to  be  expanded  which 
have  been  changed.  Without  this  extension,  the 
basic  Dynamic  Programming  algorithm  would  be 
about  a  factor  20  slower. 

An  additional  constraint  comes  from  policy  space 
U(x,k).  U(x,k)  contains  only  admissible  direc¬ 
tions  of  motion  (for  example  Induced  by  the 
allowed  maximal  accelerations  of  a  vehicle)  and 
depends  therefore  from  policy  space  of  the 
previous  stage  U(x,k+1). 


• 

Compared  to  A  and  Dijkstra's  algorithm  (Ref 
7,8),  the  described  algorithm  avoids  the  search 
of  the  minimum  element  In  set  "OPEN",  with  the 
advantage  to  get  all  optimal  paths  to  a  certain 

goal  In  a  wave  propagation  type  of  search.  Note 

• 

that  in  contrast  to  Dijkstra's  and  A  -algorithm, 
a  node  can  be  calculated  several  times  In  order 
to  get  the  optimal  path. 
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Further  increase  of  efficiency  can  be  obtained 
by  Branch-and-Bound  methods.  With  this  act hod 
(Ref  9)  the  set  of  lattice  points  which  have  to 
be  considered  can  be  reduced,  still  getting 
exact  results.  The  idea  proceeds  as  follows: 

A  node  1  for  which 

cost_at_tiae_n  (goal, node  1)  ♦ 

cost_lower_bound  (node  1, start)  > 
cost_upper_bound  (goal, start) 

holds,  needs  not  to  be  expanded  at  tine  step  n 
because  an  optinal  path  Including  that  node  i  is 
impossible  (this  follows  laaediatley  from 
Bellman’s  principle  of  optimality).  An  upper 
bound  on  the  cost  function  between  start  and 
goal  can  be  obtained  by  perturbation  methods. 

The  total  number  of  node  calculations  can  be 
reduced  by  about  30  percent. 

The  complexity  of  the  described  algorithm  is 
linear  in  the  nodes.  Suppose  a  d-diaenslonal 
lattice  with  a  total  number  of  nodes  n.  The 
number  of  time  steps  of  the  algorithm  until  the 
final  direction  matrix  is  found  is  of  order 

0(n1/d).  The  number  of  nodes  which  have  to  be 
calculated  in  one  time  step  lie  in  a  (d-1)- 
dimenslonal  wavefront l ike  hypersurface  with 

nodes  of  order  Otn1  1/d)  which  yields  a  total 
complexltly  0(n). 


5  Applications 

The  described  method  of  route  planning  can  be 
exploited  for  many  problems  of  autonomous  robot 
movement.  Examples  are  finding  routes  in  artifi¬ 
cial  environments  or  calculating  collision  free 
paths  of  robot  arms.  The  applicability  of  the 
technique  to  problems  of  this  type  and  its 
effectiveness  has  been  demonstrated  (Ref  4). 

The  algorithm  was  mainly  developed  for  planning 
optimal  paths  of  autonomous  missiles  using  digi¬ 
tal  maps.  The  following  features  are  realized  In 
our  planning  system: 

•  Different  strategies 

-  safety 

-  minimal  duration  of  flight 

-  minimal  fuel  consumption 

-  mix  of  the  above  strategies. 

e  Danger  avoidance 

By  superposition  of  regions  of  danger 
and  the  natural  environment  artificial 
danger  maps  are  created,  including: 

-  absolutely  forbidden  areas  of 
different  shape 

-  areas  with  z-dependent  degrees  of 
danger 

-  shaded  regions  within  the  range  of 
radar  waves. 

e  Aircraft  flight  dynamics 

The  characteristics  of  an  aircraft  like 
drag  and  lift  coefficient,  reference 
wing  area  and  thrust  are  used  to  calcu¬ 
late  performance  values  of  the  missile 
flying  along  a  selected  path: 

-  velocity  of  the  missile  during 
different  states  of  flight 
(horizontal,  curve,  climbing) 

-  fuel  consumption 


constraints  coming  from  flight 
dynamics: 

maximum  angle  of  climb, 
minimum  radius  of  curvature. 


•  Mandatory  navigation  points 

option  for  example  to  select  points  the 
missile  has  to  pass  for  navigation 
updating. 


6  Results 

The  result  is  an  efficient  technique  for 
strategic  route  planning  using  a  combination  of 
Dynamic  Programming  and  direct  optimization 
methods,  the  technique  allows  the  processing  of 
complex  cost  functions  of  different  nature.  It 
is  applied  to  military  flight  planning  using 
digital  maps. 

The  algorithm  is  implemented  on  a  PC-AT  with  a 
386  processor.  We  have  tested  our  method  by 
planning  flight  paths  in  different  terrains 
using  digital  maps  covering  regions  of  up  to  200 
x  200  km.  For  the  planning  task  we  dlsretlzed 
the  maps  creating  grids  of  50  x  SO  nodes.  In  the 
case  of  3-dimensional  planning  we  used  50  x  50  x 
12  lattice  points. 

We  obtained  the  following  tines  to  calculate  an 
optimal  flight  path: 

2- step  method  — >  12-15  sec 

3- D  planning  — »  80  -  90  see. 

In  future,  the  performance  will  be  further 
Increased  by  parallelizing  the  described 
algorithm  and  by  the  use  of  specialized  hard¬ 
ware. 
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SUMMARY 

Two  different  guidance  methods  are  designed 
for  the  pre— launch  phase  in  a  one-versus-one 
air  combat  situation  with  missiles.  In  both 
guidance  schemes  a  missile/target  simulation 
is  performed  to  estimate  the  miss  distance  at 
the  end  of  a  fictitious  missile  launch.  A  way  to 
do  this  in  real  time  is  described.  The  first 
guidance  method  continuously  evaluates  the 
miss  distance  for  each  aircraft  against  the 
respective  opponent.  The  guidance  is  such  that 
the  ratio  of  the  rates  of  the  miss  distances 
takes  an  optimal  value  from  the  view  of  the 
guided  aircraft.  Thus,  it  reaches  a  firing  oppor¬ 
tunity  first. 

The  purpose  of  the  second  guidance  method  is 
to  reach  a  firing  position  against  a  nonmaneu¬ 
vering  target  in  minimum  time.  Inside  the 
guidance  algorithm  the  optimal  pre-launch 
trajectory  is  approximated  by  nonlinear  pro¬ 
gramming.  It  serves  as  reference  trajectory  for 
the  guidance.  In  simulations  the  influence  of 
different  missile  and  target  strategies  in  the 
post— launch  phase  is  examined.  The  compari¬ 
son  with  an  optimal  trajectory  shows  the  near- 
-optimal  character  of  the  guidance  method. 

USX..QF  SYMBOLS. 

D  aerodynamic  drag 

g  gravitational  acceleration  (constant),  set 

to  9.80665  m/s2 
h  altitude 

n  load  factor 

q  dynamic  pressure 

R  miss  distance  at  the  end  of  a  missile/tar¬ 
get  simulation 
t  time 

T  thrust 

V  velocity 

W  weight 

x  downrange 

y  crossrange 

z  state  vector, 

z  =  (x,  y,  h,  V,  y,  x) 

Y  flight  path  angle 


t 

bank  angle 
power  setting 

X 

heading  angle 

com 

subscripts: 

to 

min 

minimum  value 

max 

maximum  value 

i 

SB 

0 

initial  value 

CM 

5 

f 

final  value 

O) 

spP 

i 

aircraft  No.  i,  i  =  1,2 

T 

target  variable 

M 

missile  variable 

superscript: 

r 

reference  value 

I.iMTRQPUCTIQN 

The  topic  of  this  paper  are  opdmal  guidance 
schemes  in  the  pre-launch  phase.  We  consider 
a  combat  situation  between  two  fighter  air¬ 
craft,  say  A1  and  A2,  each  equipped  with  an 
advanced  medium-range  air— to— air  missile. 
Optimal  guidance  of  A1  means  that  Al’s  con¬ 
trol  is  optimal  in  the  sense  of  some  perform¬ 
ance  index.  The  optimal  control  formulation 
involves  missile  performance  at  the  current 
position  or  at  some  point  on  a  reference  trajec¬ 
tory.  This  means  to  "anticipate  missile  per¬ 
formance”. 

To  evaluate  missile  performance  there  must  be 
a  criterion  to  decide  if  a  certain  state  provides 
a  firing  opportunity  for  A1  and/or  A2.  A  first 
idea  is  to  use  "firing  envelopes”,  i.e.  surfaces 
in  the  state  space,  which  envelop  the  set  of 
successful  Firing  positions  of  A1  and  A2,  re¬ 
spectively.  Menon  and  Duke  (Ref.  1),  for 
instance,  invented  a  simple  model  for  the 
firing  envelope.  However,  a  closed-form 
representation  of  the  firing  envelope  will  nev¬ 
er  be  a  realistic  model.  Note  that  the  dimen¬ 
sion  of  the  joint  state  space  is  at  least  10  if 
point  mass  models  for  A1  and  A2  are  as¬ 
sumed. 
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In  this  paper  missile/target  simulations  are 
performed  on-line  to  identify  a  firing  position. 
This  was  already  proposed  by  other  papers 
related  to  the  present  topic  (Refs.  3-6,  11).  A 
real-time  simulation  must  be  adapted  to  real — 
time  conditions.  The  present  paper  suggests  a 
simulation  model  which  needs  much  less  com¬ 
putational  effort  than  conventional  trajectory 
simulation. 

The  outcome  of  a  missile/target  encounter 
depends  on  both  the  missile  and  the  target 
guidance.  In  the  simulation  it  is  assumed  that 
the  missile  is  guided  by  Proportional  Naviga¬ 
tion  and  the  target  performs  near-optimal 
missile  avoidance.  The  guidance  law  for  mis¬ 
sile  avoidance  was  derived  by  Shinar  and 
Gazit  (Ref.  2).  The  output  of  the  simulation  is 
the  distance  R  between  missile  and  target 
measured  at  a  specified  closing  speed.  The 
missile  is  assumed  to  hit  the  target  if  R  is 
below  a  certain  bound. 

In  reality  the  target  will  not  detect  the  missile 
before  its  autonomous  phase.  Only  then  the 
target  will  switch  to  missile  avoidance.  This 
effect  is  not  modeled  in  the  present  study;  we 
rather  assume  "fire-and-forget"  missiles. 

Having  a  module  to  evaluate  missile  perform¬ 
ance  in  real  time,  optimal  guidance  schemes 
for  A1  are  designed  under  different  assump¬ 
tions  about  A2: 

a)  A2  behaves  aggressively.  In  this  case  it 
is  crucial  to  reach  a  firing  opportunity 
first. 

b)  A2  flies  straight  on  without  maneuver¬ 
ing.  A  firing  position  against  A2  is  to  be 
reached  in  minimum  time. 

A  feedback  guidance  for  a)  is  outlined  in  the 
present  paper.  First  results  are  described  by 
Prasad,  Grimm,  Berger  (Ref.  6). 

A  guidance  method  for  b)  internally  computes 
the  optimal  pre— launch  trajectory.  The  tech¬ 
nique  of  Shinar  and  Spitzer  (Ref.  7)  is  to  pre¬ 
compute  a  set  of  optimal  flight  paths  and  to 
select  the  element  fitting  to  the  current  state. 
The  present  approach  is  an  on-line  approxi¬ 
mation  of  the  optimal  trajectory  via  nonlinear 
programming.  The  method  is  described  by 
Grimm  (Ref.  8)  for  the  case  that  the  terminal 
constraint  is  a  condition  on  the  Euklidean 
distance.  In  the  present  paper  the  Euklidean 
distance  is  replaced  by  the  miss  distance  R, 
which  results  from  a  missile/target  simulation 
starting  at  the  final  position  of  interceptor  and 


target  As  in  Ref.  8  the  guidance  method 
proves  to  be  near-optimal  in  terms  of  flight 
time.  A  simulated  trajectory  of  A1  lies  in  the 
neighbourhood  of  the  optimal  one  for  the 
same  boundary  conditions. 


Each  vehicle  (aircraft  or  missile)  is  considered 
as  a  point  mass  accelerated  by  thrust,  weight 
and  aerodynamic  forces.  Assuming 

-  a  flat,  nonrotating  earth, 

-  absence  of  side  force, 

-  absence  of  wind  and 

-  a  negligible  influence  of  the  angle  of 
attack  on  to  the  direction  of  the  forces, 

the  following  equations  of  motion  hold: 


x  =  V  cosy  cosx  (1) 

y  =  V  cosy  sinx  (2) 

h  =  V  siny  (3) 

v  =  g  T  ~  Dyyh’V,n^  -  siny  (4) 

y  =  g  (n  cosn  -  cosy)/V  (5) 

X  =  g  n  sinp  /  (V  cosy)  (6) 


The  load  factor  n  and  the  bank  angle  |i  are  the 
controls  of  the  system,  n  is  the  ratio  of  lift  and 
weight;  lift  is  the  product  of  dynamic  pressure 
q,  wing  reference  area  S  and  lift  coefficient 

°L: 

q  S  CL 

n  = - -  (7) 

W 


q  =  p(h)V2/2,  (8) 

where  p  denotes  air  density.  Drag  is  structured 
as 

D(h,V,n)  =  q  S  CD(M,  CL) .  (9) 

The  drag  coefficient  CD  depends  on  the  Mach 
number  M  and  the  lift  coefficient  C^.  Accord¬ 
ing  to  (7)  is  replaced  in  (9)  by 

r  n  W 

LL"qT- 

Thus,  D  actually  becomes  a  function  of  h,  V 
and  n.  The  load  factor  is  bounded  by  the 


q  is  defined  as 


2.  VEHICLE  MODEL 
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"structural  limit"  and  the  maximum  lift  coeffi- 

cieM  clWm>: 


n  <  n 


max’ 


n  S  CL,max<M))/W- 


(10) 

(11) 


The  aircraft  is  subject  to  the  terrain  and  dy¬ 
namic  pressure  constraint: 


cies  determine  the  outcome  of  the  encounter. 
The  missile  is  guided  by  Proportional  Naviga¬ 
tion.  The  target  strategy  is  an  approximation 
of  optimal  missile  avoidance.  The  associated 
guidance  law  is  taken  from  Ref.  2  and  extend¬ 
ed  by  additional  control  modes  on  approach¬ 
ing  the  constraints  (12),  (13).  The  simulation 
is  stopped  at  a  closing  speed  of  150  m/s.  The 
output  is  the  final  distance  R,  which  is  taken 
as  a  measure  for  the  kill  probability.  Let 


h  >  0 
^  ~  ^max 


(12) 

(13) 


Aircraft  weight  is  assumed  to  be  constant 
Mass  reduction  due  to  fuel  flow  is  neglected 
since  we  only  consider  short  maneuvers.  Air¬ 
craft  thrust  is  a  function  of  altitude,  speed  and 
the  "power  setting"  £: 


T(h,V,^)  =  Tmin(h,V)  + 

^Wh’V>~Wh’V» 


(14) 


z  =  (x,  y,  h,  V,  Y,  X)T 

denote  the  state  vector  of  a  vehicle.  Since  the 
vehicle  model  and  the  guidance  law  of  both 
missile  and  target  are  fixed  R  can  be  express¬ 
ed  as  a  function  of  the  initial  states  z^  and 

ZT: 


R  =  R(zm,  zt)  (16) 

The  missile  is  assumed  to  hit  if 


T  can  continuously  be  adjusted  between  its 
minimum  and  maximum  value.  Accordingly,  £ 
is  bounded  between  0  and  1: 

05^1  (15) 

The  aircraft  model  functions 

T  T  C  C 
1  min’  1  max’  V'D’  L.max 

are  analytic  functions  approximating  table  data 
of  a  F4  aircraft  model. 

Missile  thrust  is  a  piecewise  constant  function 
of  time: 

T  =  22760  N,  0  <  t  <  3s 

("boost  phase"). 

T  =  5400  N,  3s  <  t  <  15  s 

("march  phase”). 

T  =  0,  t  >  15  s 

("coasting  phase"). 

Missile  weight  is  a  decreasing,  piecewise 
linear  function  of  time  synchronized  with  the 
thrust  profile  above.  Unlike  the  aircraft  model 
the  missile  model  is  generic. 

3.  MISSILE/TARGET-SIMULATIQNS 

The  simulation  of  a  fictitious  missile/target 
encounter  is  a  basic  module  of  pre-launch 
guidance.  Beside  the  vehicle  models  and  the 
initial  states  the  guidance  laws  of  both  vehi- 


R(zM,  z>p)  =  1  km.  (17) 

The  (arbitrary)  choice  of  the  1  km  limit  shows 
that  the  final  phase  of  the  encounter,  charac¬ 
terized  by  heavy  target  maneuvering,  is  ex¬ 
empted.  We  only  consider  the  "midcourse” 
pan  of  the  duel.  Simulation  means  to  numeri¬ 
cally  integrate  Eqs.  (1)— <6)  for  both  vehicles 
up  to  the  stopping  condition.  The  execution 
with  a  usual  Runge-Kutta  method  advancing 
in  small  steps  is  termed  "full  simulation"  in 
contrast  to  the  "simplified  simulation"  design¬ 
ed  for  real-time  application. 

The  simplified  simulation  proceeds  as  follows. 
The  first  two  integration  steps  are  identical 
with  the  boost  and  march  phase  of  the  missile. 
The  coasting  phase  is  partitioned  in  10— sec 
intervals  except  the  last  one,  where  the 
stopping  condition  is  trapped.  Each  step  repre¬ 
sents  an  initial  value  problem,  which  is  ap¬ 
proximately  solved  as  follows.  y(t)  and  x(t) 
are  modeled  as  linear  functions  along  the 
subinterval.  The  (piecewise  constant)  rates  of 
y  and  x  are  set  in  accordance  with  the  vehicle 
strategies.  The  right-hand  side  of  Eq.  (4)  is 
linearized  about  the  initial  altitude  and  speed 
at  the  beginning  of  the  step.  Thus,  an  ODE — 
system  results,  which  can  be  solved  in  closed 
form.  Details  are  given  in  Appendix  A. 

The  full  and  simplified  simulation  procedures 
are  compared  for  the  following  scenario: 
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XO 

[km] 

missile 

0 

target 

30 

yo 

[km] 

0 

0 

ho 

[km] 

10 

4.9 

V0 

[m/s] 

547.8 

310 

Yo 

[deg] 

0 

-5.7 

Xo 

[deg] 

22.9 

85.9 

The  final  times  of  the  full  and  simplified  sim¬ 
ulation  are  39.5  sec  and  41.2  sec,  respectively. 
The  miss  distances  are  6.9  km  and  5.2  km. 
The  computer  time  is  reduced  about  a  factor 
40  by  the  simplified  procedure,  if  the  full 
simulation  is  performed  with  a  fourth  order 
Runge-Kutta  method  and  a  stppsize  of  0.25 
sec.  The  difference  in  final  distance  is  the 
price  for  the  speedup.  In  view  of  the  uncer¬ 
tainties  present  in  reality  (for  instance  the 
actual  target  strategy)  the  loss  of  accuracy  on 
simplifying  the  simulation  is  a  minor  effect. 

The  turning  maneuvers  are  different  in  the  full 
and  the  simplified  simulation  (Fig.  la).  In  the 
former  one  turning  is  much  sharper.  Optimal 
missile  avoidance  basically  consists  of  a  dive 
(Fig.  lb).  After  a  few  seconds  the  dive  is 
stopped  since  the  target  approaches  its  dynam¬ 
ic  pressure  boundary  (13).  The  altitude  histo¬ 
ries  are  well  resembled  by  the  simplified  sim¬ 
ulation.  The  same  holds  for  the  speed  profiles, 
where  the  different  missile  bum  phases  can  be 
recognized  (Fig.  lc). 

4, -THE  RATIO  CRITERION 

A  pre— launch  guidance  is  designed  using  the 
miss  distance  (16)  of  a  fictitious  missile 
launch  as  a  measure  for  missile  performance. 
The  guidance  method  applies  to  a  combat 
situation  with  two  aircraft  Al,  A2,  each  of 
which  wants  to  shoot  down  his  opponent.  Let 
Zj  denote  the  current  state  vector  of  Ai  and 

R;j  =  R(Zj,Zj)  (18) 

the  miss  distance  of  a  fictitious  missile  launch 
of  Ai  against  Aj.  Because  of  his  aggressive 
intention  each  aircraft  Ai  approaches  a  firing 
position  against  his  opponent  Aj.  In  terms  of 
the  R  i j  this  means  dRjj/dt<0  as  shown  in 
Fig.  2.  The  solid  line  in  Fig.  2  is  the  preferred 
outcome  of  Al,  characterized  by  Rn  =  1  km 
and  R21  >  1  km  at  the  end.  The  dashed  line 
leads  to  a  termination  desired  by  A2. 


xm,  xt  [km] 


Fig.  1:  Comparison  of  a  full  (solid  line)  and 
simplified  (dashed  line)  missile/target  simula¬ 
tion.  la:  horizontal  projection,  lb:  altitude 
histories,  lc:  speed  profiles. 
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Fig.  2:  One— versus-one  air  combat  monitored 
in  the  (R12  ,  R2i)-space. 


Obviously,  a  reasonable  strategy  for  A1  is  to 
make  a  as  small  as  possible.  Because  of 

tana  -  ^1  (19) 

Rj2 

minimizing  a  is  equivalent  to  the  condition 
min  i  mize  ^21 .  (20) 

ni.Hl.5l  R’2 

According  to  the  chain  rule  we  have 

=  +  <2» 

The  controls  n,,  |i; ,  explicitly  appear  in  Zj 
if  the  right-hand  sides  of  ( 1 ) — (6)  are  substi¬ 
tuted.  The  gradients  of  R,j  with  respect  to  zj 
and  Z2  are  approximated  by  numerical  differ¬ 
entiation.  This  is  the  most  expensive  and  the 
most  difficult  part  of  the  guidance  law.  The 
difficulty  arises  from  the  necessity  that 

R(zi ,  z2)  is  actually  differentiable  with  respect 

to  Z!  and  z2.  This  requires  special  care  on  the 
design  of  the  vehicle  strategies  used  on  evalu¬ 
ating  R.  Furthermore,  it  demands  highest  pos¬ 
sible  accuracy  on  trapping  the  terminal  condi¬ 
tion  of  the  missile/target  simulation. 

The  objective  function  (19)  tends  to  — =®  for 
R 12  ~ *  0+0  and  R21  ^  0. 


Therefore,  (20)  only  makes  sense  together 
with  the  constraint 


R12  —  — £  <  0  .  (22) 

(22)  means  that  A1  approaches  a  firing  posi¬ 
tion  towards  A2  with  a  minimum  "speed”  e. 
The  "ratio  criterion"  (20),  (22)  can  successful¬ 
ly  be  simulated  on  the  computer.  A1  actually 
reaches  a  firing  opportunity  first  under  sym¬ 
metric  initial  conditions.  However,  the  objec¬ 
tive  function  (19)  also  involves  the  controls  of 
A2,  which  are  unknown  to  A1  in  reality. 
Therefore,  (20)  is  modified  as  follows:  Con¬ 
sider  (19)  for  constant  y,  and  Xi >  i  e. 


Yi  =  Xi  =  0  =» 

nj=cosYi,Hi=0  (23) 


for  i  =  1,  2.  Then,  (19),  (22)  only  depend  on 
the  state  variables  and  the  thrust  controls  ^ . 
Instead  of  optimizing  the  controls  nj,  p.j  we 
look  for  the  triplet  (Yi,  Xi.  Si).  which  mini¬ 
mizes  (19)  under  the  constraint  (22)  and  the 
assumption  £2  =  1: 


minimize 

7i.Xi.Si  R12 


(24) 


subject  to 

&i2  —  — £  <  0 


By  an  "o"  instead  of  a  dot  we  denote  the  rate 
of  Rjj  evaluated  under  condition  (23).  The 
minimizing  values  yr  and  xT  serve  as  "refe¬ 
rence  values"  for  the  lift  control:  nj  and  Pi  are 
such  that  Y!-»Yr  and  Xr"Xr- 

Strictly  speaking,  also  the  gradients  of  Rj, 
with  respect  to  z\  and  Z2  (see  Eq.  (21))  depend 
on  Yi  and  Xi-  This  dependence  is  neglected  to 
limit  the  computational  expense.  Both  vectors 
are  evaluated  for  the  actual  Yi  and  Xi  ar,d 
remain  unchanged  on  executing  the  minimiza¬ 
tion. 
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Fig.  3  shows  the  simulation  result  for  the  sym¬ 
metric  initial  scenario  drawn  below. 

35.  km 


I 


15° 


Both  aircraft  start  at  h  =  7  km,  V  =  437  m/s, 
y  =  0  .  A1  is  guided  by  (24).  By  the  way,  the 
original  control  law  as  formulated  in  (20)+(22) 
leads  to  similar  results.  The  Ry  and  their  gra¬ 
dients  with  respect  to  zt,  zi  (see  Eq.  (21))  are 
updated  twice  a  second  only.  This  is  the  rea¬ 
son  for  the  step-dike  histories  of  R  y  and  other 
quantities.  A2  is  guided  by  Proportional  Navi¬ 
gation  to  simulate  some  conventional  attack 
guidance. 

Due  to  the  symmetry  in  the  initial  conditions 
Rj2  and  R21  agree  at  t  =  0.  With  the  help  of 
(24)  A1  can  build  up  an  advantage 
R21  -  R12  >  4  km.  This  is  accomplished  in  less 
than  10  seconds;  the  effect  of  (24)  is  of  short 
term  nature,  obviously.  Thus,  it  does  not  make 


sense  to  consider  longer  flight  times  without 
changing  A2's  strategy. 

Let  us  look  more  closely  at  the  final  state 
(Fig.  3,  right  picture  on  the  top).  On  a  missiie 
launch  by  A2  A1  would  escape  to  the  left  in 
line— of— sight  direction.  This  would  require 
about  90°  turning  by  Al.  Al's  missile  directed 
towards  A2  would  have  to  cover  about  the 
same  heading  difference.  Al’s  success  sug¬ 
gests  the  following  interpretation.  A  certain 
vicinity  to  an  escape  direction  is  better  than  to 
fire  the  missile  directly  towards  the  opponent. 
A2  does  the  very  opposite  and  loses.  Al's 
missile  reaches  him  because  he  must  turn 
about  180°  to  evade.  On  the  other  hand  A2’s 
missile  does  not  hit  Al  although  it  could  fly 
more  or  less  directly  towards  Al.  The  reason 
is  that  Al  is  closer  to  an  escape  direction  than 
A2. 

Now  the  initial  condition  is  changed  in  favour 
of  A2:  h2  =11  km.  The  advantage  is  turned 
around  by  the  "ratio  criterion"  in  the  first  few 
seconds  (see  Fig.  4);  Al  wins  in  spite  of  a 
speed  loss  of  nearly  40  m/s.  Obviously,,  a 
speed  advantage  need  not  be  an  advantage  in 
air  combat.  Lower  speed  allows  for  a  sharper 
turn  to  escape.  This  seems  to  be  more 


VI,  V2  [m/s]  chi  [deg]  R12,  R21  [km] 
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important  than  to  provide  a  high  initial  speed 
for  the  missile  —  another  message  conveyed 
by  Figs.  3,  4.  This  is  also  the  interpretation  of 
the  minimum  thrust  phase  in  the  first  seconds. 
In  the  x-diagram  the  dashed  line  indicates  the 
reference  am  le  which  denotes  the  solution 
of  (24)  tog"  \  ,t  with  vr,  ^r.  The  actual  heading 
Xi  tends  tc  xr  as  intended  by  the  guid- 
ance  law.  After  t  =  7.5  sec  increases 
slightly.  This  is  not  a  contradiction  to  the 
constraint  of  (24)  ('ve  set  e  =  200  m/s).  Note 
that  the  modified  version  of  the  guidance  law 
considers  the  rate  of  R„  for  constant  y  and  X- 
The  actual  rate  may  differ  significantly. 

5.  MINIMUM  TIME  PRE-LAUNCH 
TRAJECTORIES 

The  guidance  method  presented  in  this  section 
is  designed  such  that  a  firing  position  against  a 
nonmaneuvering  target  is  reached  in  minimum 
time.  According  to  (17)  the  terminal  condition 
is 

R(zp  2^.f)  =  1  km  ,  (25) 

where  z  and  Zj.  denote  the  state  vector  of 

interceptor  and  target,  respectively.  The  opti¬ 
mal  control  problem  underlying  the  design  is 
to 

find  n(t),  p(t),  ^(t),  which 
minimize  tf  subject  to 

R(Zp  Zjj.)  =  1  km  .  (26) 

A  "simplified  missile/target  simulation"  (sec¬ 
tion  3)  is  performed  to  evaluate  R. 

The  guidance  law  internally  approximates  the 
optimal  pre-launch  trajectory  starting  at  the 
current  state.  The  approximation  is  done  as 
follows.  The  dynamical  model  is  reduced  to 
Eqs.  ( 1) — (4)  the  controls  being  y,  x  and  £.  The 
original  controls  n  and  p  are  formally  elimi¬ 
nated  by 

y  =  X  =  0  =>  n  =  cosy,  p  =  0  . 

The  resulting  equations  of  motion  represent  a 
reduced  model”  in  the  sense  of  Singular  Per¬ 
turbation  Theory  (Ref.  9).  The  reduction  is 
such  that  the  state  variables  y  and  x  take  the 
role  of  control  variables. 


Fig.  4:  Simulation  with  the  modified  ratio 
criterion:  altitude  advantage  for  A2. 
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The  "reduced  problem”  is  to 

find  y(t),  X(0»  5(0.  which 

minimize  tf  subject  to 

R(Zp  z, pj)  =  1  km  .  (27) 

Let  Y*(t),  x^t),  5^0  be  the  solution  of  (27) 
("reduced  solution").  The  controls  n  and  p.  are 
such  that  y-’Y^O)  and  X^XtO).  Thrust  is  con¬ 
trolled  by  5  =  ^*(0). 

The  numerical  approach  for  (27)  is  to  model  y. 
X  and  ^  as  piecewise  constant  functions.  Thus, 
the  optimal  control  problem  (27)  is  converted 
into  a  nonlinear  program  with  the  objective 
function  tf  and  the  constraint  (25).  The  para¬ 
meters  are  the  constant  y— ,  x~  and  ^-values 
in  the  subintervals  and  the  unknown  flight 
time.  The  iterative  solution  process  is  perform¬ 
ed  by  subroutine  SLSQP  (Ref.  10). 

On  each  iteration  the  optimization  method 
within  the  guidance  algorithm  requires  one  ore 
more  solutions  of  the  (reduced)  equations  of 
motion.  Since  standard  integration  methods 
are  not  suited  for  real-time  application,  a 
special  integrati  "  orocedure  for  the  the  under¬ 
lying  dynamical  A  has  been  designed. 
Details  are  given  in  Appendix  B. 

The  guidance  method  outlined  above  is  tested 
in  "simulations":  The  dynamic  system  ( 1 ) — (6) 
is  integrated  forward  with  the  controls  issued 
by  the  guidance  method.  The  simulation  is  the 
"outer  loop"  in  contrast  to  the  "inner  loop" 
represented  by  the  guidance  law.  An  overview 
is  given  by  the  following  scheme. 

simulation:  Integrate  the  equations  of  motion 
with  the  controls  taken  from  the 

guidauceJaw. 

1.  Solve  (27)  with  the  initial  state  being  the 
current  state.  Result:  "reduced  solution" 
serving  as  reference  trajectory. 

2.  Select  n  and  p  such  that  the  reference 
trajectory  is  tracked. 

The  reduced  solution  (step  1)  is  updated  each 
second  only  since  it  varies  slowly.  Step  2  is 
executed  on  each  call  of  the  guidance  algo¬ 
rithm  using  the  latest  update  of  the  reduced 
solution. 

In  the  simulation  (outer  loop)  the  target  flies 
along  a  straight  line  at  constant  altitude  with 
constant  speed.  Thus,  the  "actual"  target  flight 
path  agrees  with  the  internal  prediction  of  the 
guidance  algorithm  (inner  loop).  The  simula¬ 


tion  is  stopped  as  soon  as  terminal  condition 
(25)  is  satisfied. 

The  initial  conditions  for  the  following  exam¬ 
ple  are  given  below: 


inter—  target 
ceptor 

xo  [km]  0  30 

y0  [kni]  0  0 

ho  [km]  1  5 

V0  [m/s]  234.4  200 

Yo  [deg]  0  0 

Xo  [deg]  120  29 


The  interceptor  begins  with  a  turning  maneu¬ 
ver  to  approach  the  target.  This  phase  is  char¬ 
acterized  by  high  load  factor  and  y  <  0  (see 
Fig.  5).  The  rest  of  the  trajectory  is  a  climb 
taking  place  in  a  vertical  plane  more  or  less. 
Thus,  the  constraints  (12)  and  (13)  do  not 
become  active,  although  they  could  easily  be 
incorporated  into  the  guidance  method  (see 
Ref.  8).  After  an  intermediate  phase  with 
small  y  there  is  a  pronounced  climb  portion  at 
the  end  terminating  with  yf  =  32°.  The  physi¬ 
cal  explanation  is  that  missile  range  is  in¬ 
creased  at  high  altitude  due  to  small  air  densi¬ 
ty.  One  can  imagine  that  this  effect  does  not 
show  up  with  simple  "firing  envelopes".  The 
final  values  yf  in  this  study  are  larger  than  30° 
throughout  This  is  in  accordance  with  Ref.  1 1 
but  is  a  remarkable  difference  to  Ref.  7,  where 
Yf  is  mainly  less  than  10°.  Fig.  5  also  shows 
the  target  switching  from  idle  mode  to  missile 
avoidance  strategy  at  launch  time.  In  the  post- 
-launch  phase  the  target  accelerates  with 
maximum  thrust  and  dives  until  it  reaches  the 
dynamic  pressure  limit  (13). 

In  Fig.  5  the  simulation  with  the  feedback 
guidance  is  compared  to  the  optimal  solution 
of  problem  (26),  obtained  with  conventional 
nonlinear  programming  techniques.  The  fea¬ 
tures  described  above  are  even  more  marked 
at  the  optimal  solution.  The  associated  flight 
time  —  the  minimum  attainable  in  this  scenario 
-  is  95.93  sec.  With  a  flight  time  of  97.69  sec 
the  simulation  is  only  slightly  longer.  The 
similarity  of  simulated  and  optimal  altitude 
and  speed  histories  confirms  the  near-optimal¬ 
ity  of  the  guidance  method.  One  evaluation  of 
the  guidance  command  including  both  steps 
(step  1  is  evaluated  once  in  a  second  of  flight 
time  only)  takes  at  most  a  third  of  a  second 
computer  time  on  the  average  on  an  IBM  3090 
main  frame. 
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Fig,  5:  Time-optimal  pre-launch  maneuver. 
Optimal  solution  (dashed  line)  and  simulation 
with  a  near-optimal  feedback  guidance  (solid 
line).  Dash-dotted  line:  target  state.  Beyond 
the  launch  times  (crosses  in  the  uppermost 
diagram)  the  interceptor  trajectories  are  con¬ 
tinued  by  the  missile  state. 


Fig.  6  shows  the  infl*  jnce  of  the  target  post- 
-launch  maneuver  on  the  interceptor's  pre- 
launch  trajectory.  As  an  alternative  to  the 
missile  avoidance  strategy  used  so  far  the 
target  now  turns  to  line-of-sight  direction  at 
constant  altitude  and  speed.  Because  of  the 
initial  conditions  there  is  nearly  no  turning  in 
this  example.  Clearly,  the  target  can  now  be 
hit  earlier  from  a  longer  distance.  A  firing 
position  is  already  reached  after  42.85  sec 
(compared  to  97.69  sec,  if  the  target  tries  to 
outrun  the  missile),  y  monotonously  increases 
up  to  a  maximum  of  44°  at  launch  time. 


time  [sec] 


Fig.  6:  Time-optimal  pre-launch  trajectories 
for  different  target  behaviour  in  the  post- 
-launch  phase.  Solid  line:  The  target  tries  to 
avoid  the  missile.  Dashed  line:  The  target  flies 
at  constant  altitude  and  speed.  Beyond  the 
launch  times  (asterisks)  the  interceptor  trajec¬ 
tory  is  continued  by  the  missile  state.  Dash- 
-dotted  line:  target  state  for  the  case  of  active 
missile  avoidance. 


V 
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Next,  the  effect  on  altering  the  missile  guid¬ 
ance  law  is  examined  An  optimal  pre-launch 
trajectory  terminates  at  high  altitude  with  a 
large  flight  path  angle  to  increase  missile 
range.  This  lofting  effect  is  immediately  de¬ 
stroyed  by  the  missile  descending  to  the  lower 
target  altitude.  To  eliminate  this  paradox  be¬ 
haviour  the  missile  is  given  reference  values 
Ybr  and  ymr  for  the  flight  path  angle  in  the 
boost  and  march  phase.  yt,r  and  ymT  are 
optimized  in  the  guidance  algorithm  within 
certain  bounds.  Three  cases  are  considered: 

a)  The  missile  guidance  is  unchanged  com¬ 
pared  to  previous  examples. 

b)  Ybr>  Ymr^  11° 

c)  Ybr.  Ymr-  45° 


The  initial  values  for  this  experiment  are  the 
following: 

inter—  target 

ceptor 

x0  [km] 

0 

50 

yo  [km] 

0 

0 

ho  [km] 

5 

5 

V0  [m/s] 

400 

200 

Yo  [deg] 

0 

0 

Xo  [deg] 

0 

0 

The  table 

below  gives  the  interceptor's  flight 

time  tf  and  the  missile  flight  time  4  estimated 
in  a  simplified  missile/target  simulation  (the 
target  employs  missile  avoidance  strategy). 
The  trajectories  are  depicted  in  Fig.  7. 

tf  [sec]  tnJsec] 

a)  90.40  57.65 

b)  74.88  81.79 

c)  35.66  127.94 

The  results  confirm  the  expected  trend.  In 
cases  b)  and  c)  the  optimal  values  of  Ybr  and 
Ymr  arc  on  the  upper  bounds.  Missile  range  is 
drastically  increased  since  the  missile  is  al¬ 
lowed  to  climb  up  in  the  bum  phase.  Accord¬ 
ingly,  a  firing  position  is  reached  earlier  and 
the  missile  flight  time  increases. 

After  the  typical  dive  target  altitude  levels  out 
at  about  1  km.  Again,  this  is  the  effect  of  a 
control  mode  to  comply  with  the  dynamic 
pressure  constraint  (13).  The  structure  of  the 
interceptor's  pre— launch  trajectory  is  similar  as 
before,  y  passes  a  local  minimum  for  longer 
flight  times  (a)  and  b));  for  short  flight  times 
(case  c)>  y  monotonously  increases.  It  should 
be  added  that  the  interceptor  is  constrained  by 


Y  £  45°.  This  constraint  is  active  in  b)  and  c). 


Fig.  7:  Time— optimal  pre-launch  trajectories 
for  different  missile  guidance  in  the  bum 
phase. 

Solid  line:  usual  collision  course  guidance. 
Dashed  line:  climb  up  to  y  =  1 1°. 

Dotted  line:  climb  up  to  y  =  45°. 

Dash-dotted  line:  target  state. 

Beyond  the  launch  times  (asterisks)  the 
interceptor  trajectories  are  continued  by  the 
missile  state. 
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CONCLUSIONS 

Aircraft  guidance  in  the  pre— launch  phase 
strongly  depends  on  effects  which  are  not 
covered  by  simple  "firing  envelopes": 

-  The  range  of  a  missile  is  increased  if  it 
is  launched  at  high  altitude  and  eleva¬ 
tion. 

-  The  chance  of  the  target  to  escape 
strongly  depends  on  its  current  direction. 

A  missile/target  simulation  must  be  performed 
on-line  to  quantify  the  above  effects.  The 
simulation  must  be 

-  real-time  capable  and 

-  smooth  with  respect  to  the  initial  state, 
since  any  kind  of  guidance  will  need  the  sensi¬ 
tivity  of  the  results  with  respect  to  the  initial 
state. 

The  simulation  (and  any  guidance,  which  is 
based  on  the  simulation) 
strongly  depends  on 

-  the  vehicle  model  and 

-  the  strategy 

of  the  opponent,  who  can  alternately  take  the 
role  of  missile  or  target  in  the  simulation. 
Knowledge  about  his  model  is  an  information 
problem.  The  assumption  about  his  strategy  as 
a  target  determines  the  risk  a  pilot  is  willing  to 
take.  A  firing  position  against  an  optimally 
evading  target  bears  the  highest  risk  for  own 
survival. 

Based  on  missile/target  simulations  a  guidance 
method  ("ratio  criterion")  is  presented,  which 
successfully  improves  the  strategic  position  in 
air  combat.  However,  the  improvement  is  a 
short  term  effect  adequate  for  the  immediate 
pre-launch  phase  only.  Also,  the  guidance 
command  need  not  be  defined  as  soon  as  the 
opponent  tries  to  escape.  Simulations  show 
that  an  advantageous  strategic  position  is  char¬ 
acterized  by  the  ability  to  turn  to  line-of- 
— sight  direction  in  short  time.  This  may  re¬ 
quire  reduced  speed  and  an  angular  vicinity  to 
the  escape  direction  even  if  the  missile  cannot 
be  directly  aimed  at  the  opponent.  Obviously, 
high  speed  need  not  be  favourable  on  entering 
a  beyond  visual  range  combat  situation. 

Another  guidance  method  leads  to  a  firing 
position  against  a  nonmaneuvering  target  in 
nearly  minimum  time.  The  firing  position  is 
characterized  by  high  altitude  and  elevation  at 
the  cost  of  speed.  The  terminal  phase  of  the 
pre— launch  trajectory  is  a  steep  climb,  which 
constitutes  the  whole  trajectory,  if  the  flight 
time  is  short.  Missile  range  is  significantly 
increased  if  the  climb  may  be  continued  by 


the  missile  during  its  bum  phase. 

The  guidance  methods  in  this  paper  are  exam¬ 
ples  how  to  taylor  trajectory  simulation  and 
optimization  for  real-time  application.  The 
basic  idea  is  to  design  a  fast  integration  meth¬ 
od  for  the  special  differential  equation  system. 
A  quite  different  philosophy  is  to  precompute 
sets  of'  (optimal)  trajectories  ("extremal 
fields")  and  to  pick  an  element  fitting  to  the 
current  situation.  The  nice  feature  of  this  ap¬ 
proach  is  that  it  needs  nearly  no  computing 
time.  However,  precomputed  data  depend 

—  on  special  vehicle  models  and 

-  the  special  mathematical  formulation  of 
the  mission  objective. 

Precomputed  data  must  be  recalculated  if  a 
detail  in  one  of  the  two  items  above  is  altered. 
Because  of  enhanced  flexibility  we  prefer  the 
on-line  computation  of  required  flight  path 
predictions.  This  approach  gains  attraction 
from  the  rapid  development  of  high  perform¬ 
ance  computers  and  the  effectiveness  of  mod¬ 
em  numerical  algorithms. 

Beside  partial  automation  of  aircraft  guidance 
the  methods  described  in  this  paper  could  be 
used  in  a  pilot's  decision  aid.  By  means  of 
missile/target  simulations  the  chance  to  hit  an 
aggressive  or  defensive  target  is  estimated. 
This  yields  a  lower  and  an  upper  bound  for  the 
kill  probability.  The  same  calculation  is  re¬ 
peated  with  reversed  roles,  i.e.  missile  firing 
by  the  opponent.  The  results  —  the  chance  to 
hit  and  the  degree  of  threat  -  are  continuously 
displayed  to  the  pilot.  While  this  is  only  an 
instantaneous  risk  analysis,  fictitious  mini¬ 
mum-time  pre— launch  trajectories  of  the  own 
and  the  adversary  aircraft  can  be  compared  to 
predict  the  event  of  an  encounter.  The  superior 
fighter  reaches  a  firing  opportunity  first.  In 
any  case  the  results  would  have  informational 
character  and  would  not  override  the  pilot’s 
decision. 

REFERENCES 

1.  Menon,  P.K.A.  and  Duke,  E.L.,  "Time- 
-Optimal  Aircraft  Pursuit— Evasion  with 
a  Weapon  Envelope  Constraint",  Pro¬ 
ceedings  of  the  American  Control  Con¬ 
ference,  San  Diego,  Ca.,  May  1990,  pp. 
2337-2342. 

2.  Shinar,  J.  and  Gazit,  R.,  "Optimal  No- 
-Escape  Envelopes  of  Guided  Missiles", 
AIAA  Paper  No.  85-1960  CP.  A1AA 
Guidance,  Navigation  and  Control  Con¬ 
ference,  Snowmass,  Co.,  1985. 


23-12 


3.  Jannark,  B.,  "A  Missile  Duel  Between 
Two  Aircraft",  J.  Guidance,  Control  & 
Dynamics,  Vol.  8,  No.  4,  July— August 
1985,  pp.  508-513. 

4.  Moritz,  K.,  Polis,  R.  and  Well,  K.H., 
"Pursuit-Evasion  in  Medium-Range 
Air-Combat  Scenarios",  Comp.  Math. 
Appl.,  Vol.  13,  No.  1—3,  1987,  pp. 
167-180. 

5.  Grimm,  W.,  Prasad,  U.R.  and  Well, 
K.H.,  "Open-Loop  Guidance  for  Pre- 
— Launch  Maneuvering  in  Medium- 
-Range  Air-Combat",  Proceedings  of 
the  27th  IEEE  Conference  on  Decision 
&  Control,  Austin,  Texas,  Dec.  1988, 
pp.  1442-1447. 

6.  Prasad,  U.R.,  Grimm,  W.  and  Berger, 
E.G.,  "A  Feedback  Guidance  for  Pre- 
— Launch  Maneuvering  in  Medium- 
-Range  Air-Combat  with  Missiles",  in: 
Differential  Games  and  Applications, 
T.S.  Basar  and  P.  Bernhard  (eds.).  Lec¬ 
ture  Notes  in  Control  and  Information 
Sciences,  Vol.  119,  1988,  pp.  86-96. 

7.  Shinar,  J.  and  Spitzer,  A.,  "Global  Opti¬ 
mization  of  Medium— range  Air-to-Air 
Interceptions",  Proceedings  of  the  Amer¬ 
ican  Control  Conference,  Atlanta, 
Georgia,  May  1988,  pp.  977—982. 

8.  Grimm,  W.,  "A  Numerical  Approach  for 
On-Line  Guidance  of  Aircraft",  Pro¬ 
ceedings  of  the  25th  Conference  on 
Decision  &  Control,  Athens,  Greece, 
Dec.  1986,  pp.  683-687. 

9.  Ardema,  M.D.,  "An  Introduction  to 
Singular  Perturbations  in  Nonlinear 
Optimal  Control",  in;  Singular  Perturba¬ 
tions  in  Systems  and  Control,  M.D. 
Ardema  (ed.),  CISM  Courses  and  Lec¬ 
tures  No.  280,  Springer,  Wien  —  New 
York,  1983. 

10.  Kraft,  D.,  "A  Software  Package  for  Se¬ 
quential  Quadratic  Programming", 
DFVLR-FB  88-28,  1988. 

11.  Well,  K.H.,  "Medium  Range  Intercept 
Maneuvers  with  a  Missile",  Proceedings 
of  the  American  Control  Conference, 
San  Diego,  Ca.,  May  23-25,  1990,  pp. 
2343-2348. 


reisfjtfawffsn 


y(t)  =  '*)  +  »•*,  (Al) 

X(0  =  Xo  +  t’*-  (A2) 

y  and  %  are  selected  in  accordance  with  the 
guidance  strategies  of  missile  and  target,  re¬ 
spectively.  From  Eqs.  (5),  (6)  the  controls  can 
be  determined: 


n  cosji 


n  sinp. 


=  iv  +  ( 

g 

=  *v 


n  =  V(n  cospt)2  +  (n  sinfi)2  (A5) 

The  load  factor  in  D(h,V,n)  is  replaced  by 
(A3)  —  (A5).  Thus,  drag  becomes  a  function  of 
h,  V,  and  cosy: 

D(h,  V,  n)  =  D(h,  V,  cosy)  (A6) 

Now,  T  and  D  are  linearized  about  ho,  V0  and 
Yo.  The  resulting  expressions  contain  the 
altitude  difference  h(t)  —  ho,  which  is  approxi¬ 
mated  by 


h(t)  -  h0  =  V0  f  siny(T)dx  = 

0 

V0  (cosy0  -  cosy(t))  /  y  (A7) 

Finally,  Eq.  (4)  takes  the  form 

ay(V  — V0)  =  a(V  — V0) 

-  A  •  siny  —  B  •  cosy  -  C.  (A8) 

a.  A,  B,  C  are  constants  (within  the  respective 
step).  They  mainly  consist  of  partial  deriva¬ 
tives  of  thrust  and  drag,  which  are  evaluated  at 
the  initial  point  of  the  step.  (A8)  is  a  linear 
inhomogeneous  equation,  which  can  be  solved 
in  closed  form.  Having  the  V(t)-solution  x(t), 
y(t),  and  h(t)  can  also  be  represented  in  closed 
form  since  y(t)  and  x(0  are  assumed  to  be 
linear. 


Let  xo,  yo,  ho,  Vo,  Yo,  Xo  denote  the  state  vec¬ 
tor  of  a  vehicle  at  the  beginning  of  an  integra¬ 
tion  step.  Within  the  step  the  rates  of  y  and  x 
are  given  constants: 


The  "reduced"  dynamic  model  with  the  control 
variables  y,  x  and  %  consists  of  the  following 
differential  equations: 
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x  =  V  cosy  cosx 

(Bl) 

y  =  V  cosy  sin% 

(B2) 

h  =  V  siny 

(B3) 

V  =  g 

[T  ^  D<^>  siny] 

(B4) 

The  load  factor  in  the  drag  function  is  re¬ 
placed  by  n  =  cosy.  Analytical  approxima¬ 
tions  of  T  and  D  are  chosen  which  let 
Eq.  (B4)  appear  in  the  form 

2  i 

V  =  I  ai(h,Y,5)  V  .  (B5) 

i=0 


E.g.  a  suitable  model  of  Tm  „  is 

2  i 

Tm«  =  I  fi(h)  M\ 

i=0 

To  solve  (27)  y  and  £,  are  modeled  as  piece- 
wise  constant  functions.  If  also  the  h-argu- 
ment  in  a;  is  kept  constant  within  a 
subinterval,  (Bl)— (B3)  together  with  (B5) 
have  a  piecewise  closed— form  solution. 


AO-P007  507 


:4-i 


FI  ZZY  GUIDANCE  SYSTEM  EVALUATION 

by 

J.R.  Martin.  F.  Sanchez.  P.V.  Cuenca.  L.M.  Rodriguez  and  J.B.Ecija 

Laboratorio  de  Guiado 
Instituto  Nacionai  de  Tecnica 
Aerospacial 

Carretera  de  Ajalvir.  Km  4 
Torrejon  de  Ardoz 
Madrid  28850 
Spain 


92-16185 


ABSTRACT 

A  study  is  described  that  compares  the 
capability  of  a  fuzzy  logic  controller 
with  a  classical  controller  P+D 
(proportional  plus  derivative).  The 
model  used  for  this  investigation  is 
the  attitude  control  of  a 
microsatellite  launcher,  during  the 
first  stage  of  flight. 

This  model  has  been  chosen  because 
performs  a  very  unstable  plant,  the 
launcher  is  understood  without 
stabilization  surfaces  and  only  the 
body  is  considered  as  generator  of 
aerodynamics  forces.  Movable-nozzle  TVC 
(Thrust  Vector  control)  will  be  used  as 
flight  control  device.  The  problem  is 
studied  under  3DOF  ( three  degrees  of 
freedom)  simulation  at  two  levels, 
software  and  hardware.  The  concept 
formulated  in  this  work  is  the  analysis 
of  the  fuzzy  rules ,  that  performs 
robust  control  during  the  flight. 

It  has  been  used  as  perturbations , 
a  wind  profile  and  missalignments  in 
the  launcher.  The  wind  model  generates 
a  wind  velocity  vector,  which  is 
constant  throughout  each  run.  The  wind 
velocity  vector  is  parallel  to  the 
surface  of  the  earth. 

INTRODUCTION 

The  study  has  two  levels: 

-Simulation  under  software  rrodel  of 
different  subsystems.  A  PORTRAN77  code 
subroutines  are  studied,  in  order  to 
generate  the  rules  needed  in  the  fuzzy 
logic  controller  emulator.  Rate  gyro 
model,  electronic  integration,  movable 


nozzle  actuator  are  modelled  with  real 
test  data. 

-Complete  simulation  with  HWIL 
(Hardware  In  the  Loop)  testing, 
combines  a  real  time  simulation  with 
flight  hardware.  This  hardware 
consist: 

-Digital  real  time  Gould  32/97 
computer. 

-Interfaces  to  the  digital 
computer  (A/D,  D/A) . 

-Fuzzy  logic  Hardware. 

-Rate  gyro  and  electronic 
integrator . 

-One  rotational  motion  simulator 
(CARGO  flight  table). 

-Torque  simulator  (CARGO) 

Finally  software  and  hardware 
models  are  compared  under  Monteearlo 
method  an  conclusions  are  presented. 

LAUNCHER  MODEL 

The  basic  vehicle  configuration  is 
presented  in  figure  1.  Some  of  the 
variables  used  in  this  report  are 
defined  in  this  figure,  the  list  of 
simbols  is 

a  distance  from  gimbal  point  to 
center  of  gravity, m 
b  distance  from  center  of  gravity  to 
center  of  pressure,  m 
c  distance  from  nose  to  center  of 
pressure,  m 

CG  center  of  gravity 
CP  center  of  pressure 
GP  gimbal  point 

g  gravitational  acceleration,  m/sec^ 
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1 

I  moment  of  inertia,  Kg-m 
K*  attitude  gain  constant 
ic,  attitude  rate  gain  constant 
m*  mass.  Kg 

s  Laplace  operator,  sec'1 
t  time,  sec 

T  thrust,  N 

v  velocity,  m/sec 
a  vehicle  angle  of  attack,  rad 
wind  angle,  rad 

6  thrust  vector  deflection  angle,  rad 
0  launcher  attitude,  rad 
0'  launcher  rate  attitude,  rad/sec 
0C  ccrrmanded  launcher  attitude,  rad 
q  dynamic  pressure,  N/nr 
S  area  of  maximum  body  section,  nr 
M  Mach  number 
o  air  density.  Kg /nr 
Cj  drag  force  coefficient 
CM  normal  force  coefficient 

Figure  1  shows  the  vehicle 
aerodynamic  forces  that  act  on  it. 
These  forces  may  be  assumed  to  be 
concentrated  at  a  single  point,  the 
vehicle  center  of  pressure.  In  this 
case  results  an  aerodynamical  ly 
unstable  vehicle,  that  is  stabilized  by 
the  control  system.  A  rigid  body 
configuration  is  assumed,  and  three 
degrees  of  freedom  model  is  considered. 
Therefore, vehicle  bending,  and 
aeroelastic  effects  are  not  taking  in 
account.  .The  feedback  variables  are  the 
attitude  and  attitude  rate. 

The  vehicle  equations  of  motion  for 
a  rigid  body  configuration  are; 

nri~Tcoa  (0-y-fl)  -Deo a  (0-y) 


-Main  (0-y)  -mgsiny 


mvy*TSin(0-y-6) -Dsin (0-y) 


*Ncob  (0-y)  -jngreosy 


J&*Taainb  +Nb 


a-6-y-a„ 


where 


q  =  1/2  o  v2 
D  =  q  S  Cd 
N  =  q  S  CM  a 

cd  =  cd0  +  CM  “2 

The  vehicle  parameters  and 
aerodynamic  data  are  those  of  a 
hypothetical  launch  vehicle  with  the 
following  initial  parameters: 

-total  length . 20  m 

-first  stage  length . 10  m 

-nose  length . 1  m 

-diameter . 1  m 

-distance  from  gimfoal  point 
to  center  of  gravity. . .8.2  m 
-distance  from  center  of 


gravity  to  center 

of  pressure . 11.2  m 

-thrust  at  sea  level. 606500  N 

-time  of  flight . 44  s 

-mass . 19421  Kg 


Figure  2  shows  the  value  of  the  C« 
coefficient  as  a  function  of  Mach 
number  that  is  the  same  for  all 
altitudes.The  C^,  coefficient  is 
considered  constant,  and  equal  2. 

ACTUATOR  MODEL 

TVC  are  used  as  control  device  to 
stabilize  the  system,  and  is  performed 
by  a  movable  nozzle  through  an 
hydraulic  actuator.  The  transfer 
function  between  the  6C  (delta  ccrmand) 
and  the  real  deflection  of  the  thrust 
vector  6  is  a  second  order  transfer 
function  approximation,  obtained  from 
a  real  test  data  of  the  TVC  actuator, 
with  danping  coefficient  1.4  and 
natural  frequency  35  rad/s,  then 

«  1 


$e  A  s2  B  s  +  1 


A  =  8.16  10'*  sec2 

B  =  8.0  10'2  sec 

The  rraximxn  deflection  angle 
permitted  to  maintain  stability  when 
disturbances  are  presented  is  3 
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degrees. The  hardware  model  is  performed 
by  a  hydraulic  torque  table,  that  has 
a  delay  in  order  to  simulate  the 
transfer  function. 

GYRO  MODEL 

the  measurement  of  the  rate  and 
attitude  angle  is  performed  by  a  rate 
integrating  gyro  NORTHROP  G1-G6-650B, 
that  is  modeled  by  a  second  order 
transfer  function  approximation ,  with 
damping  coefficient  0.625  and  natural 
frequency  180  rad/s. 

The  transfer  function  employed  in 
the  software  model  is 

0  1 

0a  C  s2  +  D  s  +  1 

with 

C  =  3.0  10  5  sec^ 

D  =  6.87  10'3  sec 

One  axis  of  the  flight  table,  is 
used  to  mount  the  RIG  when  the  hardware 
model  runs  .One  of  the  five  degrees  of 
freedom  can  be  feedback  with  rate  and 
will  be  used  to  move  the  table  in  this 
mode. 

SIMULATION  OVERVIEW 

Canplete  software  model  is 
introduced  in  the  QOUID  conputer  that 
will  run  out  of  time,  because  the 
routine  that  performs  the  fuzzy  rules 
takes  too  time,  that's  no  problem 
because  there  are  not  hardware  in  the 
loop. Then  the  results  can  be  compared 
with  those  obtained  when  the  simulation 
runs  in  real  time  with  hardware  in  the 
loop. Figure  5  shows  a  schematic  block 
diagram  that  highlight  the 
interconnection  between  the  different 
conponents  of  the  software  simulation. 

Fourth  order  Runge-Kutta  integrator 
are  used  to  obtain  the  nunerical 
integration  of  the  differential 
equations  that  performs  the  dynamic  of 
the  launcher,  actuator  model,  gyro 
model  and  electronic  integration . In 
order  to  decide  on  the  sampling 
frequency  in  the  simulation,  we  have 
performed  several  runs  with  the  dynamic 
of  the  launcher  and  taking  in  account 


the  length  of  the  bus  word,  the 
stability  of  the  integrator,  the 
bandwith  of  other  conponents  of  the 
simulation  and  the  error  propagation, 
the  sampling  frequency  will  be  200  Hz. 
This  frequency  doesn't  permit  to  run 
the  simulation  in  real  time  when  the 
fuzzy  emulator  is  running  in  the 
computer. 

Figure  6  shows  the  block  diagram 
of  the  hardware  in  the  loop 
sinulation,  that  consist  in  replacing 
the  model  of  the  RIG  for  the  real  RIG 
and  the  flight  table,  the  actuator  for 
the  torque  table  and  the  fuzzy 
emulator  for  the  hardware  prototype 
that  will  be  described  later. 

The  classical  and  the  fuzzy 
controller  are  compared  in  both 
simulations  hardware  and  software. 

ERROR  SOURCE 

The  launch  attitude  is  the  only 
error  considered  and  have  a  random 
variation  between  +1  degree  and  -1 
degree  on  the  initial  alignment  gj=  90 
degrees.  A  constant  probability 
density  function  is  employed  to  obtain 
the  random  misalignement. 

WINDS 

Figure  4  shows  the  wind  model 
profile  that  generates  a  wind  velocity 
vector  that  is  parallel  to  the  surface 
of  the  earth. This  profile  will  be  the 
same  in  all  runs  without  variations. 

The  inclusion  of  wind  require  a 
change  in  the  way  the  angle  of  attack 
is  calculated  in  the  simulation. 

AUTOPILOT 

Figure  3  shows  the  autopilot  block 
diagram  that  is  studied  to  obtain  the 
classical  controller  as  a  reference  to 
compare  with  the  fuzzy  controller  .The 
autopilot  is  characterized  by  the 
gains  K*  and  K., ,  that  are  calculated 
in  order  to  obtain  a  good  control 
during  the  first  stage  of  flight  and 
will  be  constant  all  the  time. Pole 
placement  method  is  employed  to  obtain 
a  robust  control  during  the  flight. 
The  analysis  is  performed  by 
linearizing  about  the  vehicle 
equations  of  motion  at  constant 
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time. This  procedure  results  in  a  set  of 
third  order  equations  an  the  autopilot 
gains  constants  are  calculated  in  a  set 
of  times  during  the  flight  (one  of  those 
are  for  the  maxinun  dynamic  pressure) . 
The  classical  autopilot  will  run  in  the 
GOULD  computer  for- all  the  cases  under 
study.  The  requirements  needed  to 
obtain  the  gains,  are 

-the  nominal  attitude  g,  =  90 
degrees 

-maximum  deviation  of  gn  1  degree 

-maximum  attitude  rate  S' =  1 
degree/sec 

With  this  requirements  we  obtain 
that  the  gains  are 

V  2  K,.  «  1 

DESItJi  OF  TOE  FUZZY  LOGIC  ajnBQT.T.nt 

The  fuzzy  controller  presented 
performs  the  following  type  of  fuzzy 
inferences 

if  x  is  Xi  and  y  is  Yi,  then  c  is  Ci 

Where  "i"  indicates  the  rule  number. 

Each  control  rule  has  two 
antecedents  and  one  consequent .The 
linguistic  elements  used  that  are  named 


labels  are 

PL 

positive  large 

(+5.0) 

PM 

positive  medium 

(+3.3) 

PS 

positive  small 

(+1.7) 

ZR 

approximately  zero(  0.0) 

NS 

negative  snail 

(-1.7) 

negative  medium 

(-3.3) 

NL 

negative  large 

(-5.0) 

NG 

negation  (not  defined) 

and  are  defined  by  their  membership 
function  that  will  be  triangle¬ 
shaped,  the  center  point  of  each  label 
is  the  number  beside  the  label  that 
corresponds  to  volts  in  the  hardware. 

The  set  operations  of  fuzzy  sets 
will  be  defined  via  their  membership 
functions, and  Min-Max  operations  are 
utilized  to  perform  the  rules  <1). 
Figure  7  shows  an  exanple  of  how  works 
the  fuzzy  controller  with  two  rules. The 
fuzzy  emulator  has  to  reproduce  the 
characteristics  of  the  hardware  that 
can  perform  12  rules  only,  then  the 


maxiirun  rules  permitted  in  the 
emulation  are  12  rules. 

To  obtain  the  rules  that  control 
the  launcher  under  the  limitations 
imposed  it  would  be  necessary  an 
expert  to  select  the  suitable  rules 
that  could  control  the  latffacher  for 
all  situations  that  could  be 
presented.  In  our  case  we  take  as 
reference  the  classical  autopilot  and 
changing  the  initial  conditions  we 
will  obtain  the  global  tendency  of  the 
system  for  this  type  of  errors. 

Figure  16  shows  the  state  space 
attitude  and  rate  of  the  nominal  run 
with  the  initial  conditions  gn  =  90 
degrees ,§'=0  degrees/sec  and  figures 
17  and  18  the  runs  with  initial 
conditions,  g=89  degrees  and  g=91 
degrees  with  g'=0  degrees/sec 
respectively,  under  the  software  model 
and  the  wind  profile. The  region  of 
interest  of  the  state  space  is  taken 
to  be  from  -1  degrees/sec  to  +1 
degrees/sec  for  the  rate  and  from  89 
degrees  to  91  degrees  for  the 
attitude.  A  cell  state  space  is 
constructed  to  match  the  results 
obtained  under  different  initial 
conditions  from  the  classical  model 
into  the  fuzzy  labels,  then  we  obtain 
the  different  possible  paths  that 
performs  the  donuin  of  interest  and 
the  zones  where  is  necessary  the 
existence  of  rules.  The  frequency  of 
each  cell  indicates  the  necessity  of 
more  that  one  rule  and  obtain  the 
overlapping  of  the  rules  to  get  more 
effective  inferences. 

The  results  obtained  from  the 
figures  16,17  and  18  are  notched  in 
the  cell  state  space  of  the  figures 
8,9  and  10  respectively.  Is 
interesting  highlight  that  exist 
discontinuity  between  cells  but  is  due 
because  the  sampler  frequency  is  not 
sufficient  to  get  points  into  inter 
cells  and  the  high  speed  of  the 
classical  control  to  go  into  the 
periodic  zone.  The  periodic  zone  is 
determined  by  the  set  of  cells  that 
have  the  highest  frequency.  If  the 
wind  is  blowing  in  the  opposite 
direction,  the  results  are  symmetric 
and  is  considered  when  the  influence 
zone  is  determined .  Figure  11  shows  the 
interest  zone  and  figure  12  shows 
the  periodic  zone.  With  this  results 


the  figure  14  shows  a  set  of  seven 
rules  that  were  programed  but  the 
launcher  turned  unstable  at  22  sec  of 
flight  .That  means  that  the  influence 
zone  is  bigger  than  that  obtained 
before  ,(  see  figure  13)  then  a  set  of 
eleven  rules  were  programed  ( see  figure 
15)  with  satisfactory  results  .  The 
figure  19  shows  the  output  attitude  and 
rate  when  the  fuzzy  controller 
emulator  is  programed  with  eleven 
rules,  the  results  seem  to  be 
satisfactory  until  33  seconds  after 
launching,  after  this  time  the  launcher 
is  maintained  stabilized  .  Figure  20 
plots  the  attitude  as  a  function  of 
time  but  the  rate  presents  oscillations 
with  values  1.5  degrees /sec.  Adding  two 
rules  more  figure  21  shows  that  the 
amplitude  of  the  oscillation  falls 
inside  the  values  permitted.  Figures  22 
and  23  plot  the  attitude  and  rate  as 
function  of  time  with  thirteen  rules. 

HARDWARE  PROTOTYPE 

The  fuzzy  controller  hardware 
developed  by  Takeshi  Yamakawa,  are 
defined  in  (1) ,  is  a  prototype  that  can 
performs  12  rules  in  parallel  running 
a  high-speed.  Each  rule  has  three 
antecedents  and  one  consequent  that  can 
be  assigned  to  different  types  of 
membership  function  shapes,  in  this 
case  we  assign  triangle-shapes  in  all 
cases,  and  the  center  of  gravity  method 
is  adopted  to  transform  the  fuzzy 
output  in  non  fuzzy  output.  The  voltage 
range  adopted  by  this  prototype  is 
between  -5  volts  and  +5  volts  and  we 
have  to  adapt  this  range  to  the  others 
hardware  systems  involved  in  the 
simulation.  More  detailed  infomation 
about  how  works  this  prototype  can  be 
seen  in  ( 2 ) . 

SOFTWARE  SIMULATION 

Figure  5  shows  the  block  diagram  of 
the  software  s initiation  employed  to 
conpare  the  fuzzy  controller  and  the 
classical  controller.  Montecarlo method 
has  been  used  to  compare  the  behavior 
of  both  controllers  at  the  end  of  first 
stage  at  44  sec  of  flight  time.  We  will 
focus  to  the  attitude  at  this  time, 
when  random  initial  misalignement  is 
randomly  varied.  Figure  24  shows  the 


attitude  as  function  of  time  without 
missalignment  (only  with  wind  profile) 
of  both  controllers,  the  results  are 
inside  the  basked  but  the  behavior  of 
the  classical  controller  seems  to  be 
better.  For  the  same  case  figure  25, 
26,27  show  the  rate  attitude  as 
function  of  time,  the  thrust 
deflection  angle  as  function  of  time 
and  the  state  space  attitude  and  rate 
respectively. 

The  results  of  200  runs  under 
Montecarlo  method  are  presented  by  the 
distribution  function  of  the  figure 
28,  where  the  classical  controller  has 
better  results.  Is  important  to  take 
in  account  that  this  don't  means  that 
the  classical  controller  are 
absolutely  better,  because  the  fuzzy 
controller  only  has  11  rules  and  the 
deffuzzyfier  could  be  changed  to 
obtain  better  results. 

HARDWARE  M3DEL 

The  block  diagram  of  the  hardware 
model  is  shown  in  figure  6,  in  this 
case  the  fuzzy  controller  is  the 
prototype  that  is  in  the  loop  of  the 
simulation.  The  results  are  slightly 
the  same  as  the  software  model,  the 
difference  is  presented  by  the  noise 
involved  in  the  simulation.  The 
attitude  ,the  rate  attitude  and  the 
trust  deflection  angle  as  function  of 
time,  are  presented  in  figures  29,30 
and  31,  respectively. 

CONCLUSIONS 

The  problem  formulated  here  is  how 
is  the  behavior  of  fuzzy  controllers 
in  the  aeronautics  field,  and  if  is 
interesting  go  on  in  the  study  of  this 
types  of  controllers,  we  are  not 
interested  in  optimize  a  guidance 
system  for  a  specific  launcher  in  this 
study.  In  this  way  the  conclusions  are 
satisfactory.  The  fuzzy  controllers 
seems  to  have  more  robustness  than 
the  classical  controllers,  but  the 
analysis  of  this  type  of  controllers 
fails  in  the  absence  of  a  closed 
theory.  There  are  several  methods  like 
the  cell  to  cell  method  of  (3).  The 
method  employed  in  the  analysis  of  the 
fuzzy  rules  has  been  done  with  the 
classical  controller,  but  the  same 
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method  can  be  employed  from  the 
unstable  dynamic  model  analyzing 
smaller  cells  by  the  same  method 
in  the  time  scale  of  one  step  of 
integration . 
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1.  SUMMARY 

This  paper  focuses  on  the  architectural  approach,  both  in 
hardware  and  software,  taken  for  the  parallel  DMuse  project,  and 
its  application  to  in-flight  Mission  Management.  This  includes 
a  description  of  the  Muse  Real  Time  Intelligent  Knowledge 
Based  Systems  (IKBS)  toolkit  as  it  now  stands  and  the  alterations 
necessary  to  provide  this  system  on  a  multi-processor  platform 
to  produce  the  Distributed  Muse  (DMuse)  toolkit. 

2.  INTRODUCTION 

The  IKBS  section  of  what  was  then  the  Royal  Aircraft 
Establishment.  Famborough  -  now  the  Defence  Research 
Agency  -  was  formed  to  reduce  aircrew  workload  in  both  fixed 
and  rotary  winged  aircraft  using  Artificial  Intelligence 
technology.  It  was  recognised  some  years  ago  that  a  real  time 
IKBS  toolkit  would  be  necessary  to  tackle  the  large  Mission 
Management  (MM)  problems  we  were  approaching.  After  some 
feasibility  and  study  work  had  been  completed  a  specification 
was  given  to  Cambridge  Consultants  Ltd.  (CCL)  of  Cambridge, 
England,  for  development.  This  project  has  taken  approximately 
sixteen  man  years  work  to  reach  its  current  state.  However, 
despite  the  growing  speed  of  both  C"— plex  Instruction  Set 
Computer  (CISC)  and  Reduced  Instruction  Set  Computer 
(RISC)  micro-processors,  execution  speed  was  anticipated  to 
become  unacceptable  for  the  larger  knowledge  bases  necessary 
in  full  scale  MM  applications.  Previous  such  applications  have 
been  split  over  multiple  machines  on  an  Ethernet  network, 
working  on  separate  but  communicating  knowledge  bases,  and 
the  bottle-neck  was  found  to  be  both  execution  speed  and 
communication  bandwidth.  The  solution  to  this  is  seen  to  be  a 
multi-processor  hardware  platform,  which  we  believe  can 
alleviate  both  these  problems. 

3.  MUSE 

Muse  is  a  powerful  real-time  Artificial  Intelligence  toolkit 
produced  by  CCL  to  a  specification  developed  by  DRA.  It 
consists  of  a  full  development  environment,  including  a 
structured  editor,  a  run-time  browser  and  a  debugging  facility. 
Various  language  systems  are  also  provided  to  give  greater 
efficiency  with  differing  types  of  application.  Muse  is  ideally 
suited  to  applications  such  as  fault  diagnosis,  intelligent 
scheduling,  condition  monitoring  and  knowledge  based 
simulation.  It  has  also  been  designed  with  embedded  systems  use 
in  mind. 

The  Muse  package  contains  an  integrated  set  of  knowledge 
representation  language  modules.  These  comprise  of  a  flexible 
frame  language,  a  forward  producuon  system  (FPS)  and  a 
backward  chaining  system  (BCS)  which  are  supported  by  and 
partly  written  in  PopTalk  -  an  object  oriented  procedural 
language.  This  is  an  implementation  of  the  POP  language, 
written  in  C.  but  which  includes  the  object  onented  programming 
tools  used  in  the  Smalltalk  language.  The  frame  system  sitting 


on  top  of  this  includes  features  which  allow  applications  to  be 
easily  written  for  real-time  execution,  such  as  procedural 
attachment  and  message  passing. 

In  the  FPS  and  BCS  rule-based  reasoning  systems,  rules  can 
match  and  modify  objects  in  databases.  Those  in  the  FPS  fire  in 
a  data-driven  manner  using  the  efficient  RETE  matching 
algorithm,  while  rules  in  the  BCS  are  goal -driven  and  provide  an 
automatic  backtracking  search.  BCS  rule  systems  are  best 
known  for  their  use  in  Prolog.  Both  the  FPS  and  BCS  use  the 
same  database  structure  and  can  therefore  easily  share 
information. 


System  Development: 
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Figure  1 :  The  Muse  Toolkit 

Muse  also  provides  support  for  the  modular  development  of 
applications.  These  facilities  include  databases,  knowledge 
sources,  notice  boards,  agenda-based  scheduling,  collections 
and  data  capture  channels.  Also  very  important  in  real-time 
applications  is  the  design  of  the  knowledge  sources,  as  it  allows 
the  safe  interruption  of  an  existing  activity  to  deal  with  a  new 
event. 


The  development  tools  provided  with  the  Muse  package  include 
a  windows-based  structured  editor,  a  run-time  structure 
browser,  and  the  MUDDLE  run-time  debugging  system.  The 
structured  editor  provides  a  creation  and  manipulation  tool  for 
the  object  definitions  which  make  up  all  Muse  applications.  Even 
rules  are  treated  as  objects.  Details  of  the  actual  code  can  be 
‘folded’  away  out  of  sight  where  necessary  to  give  the  user  a  view 
over  the  entire  structure.  An  interface  to  the  EMACS  editor  is 
also  provided,  as  is  an  interface  to  the  UNIX  Source  Code  Control 
System  (SCCS).  to  maintain  a  full  backtrace  of  application 
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development.  The  browser  tool  provides  the  same  user  interface 
as  the  editor  but  allows  the  examination  of  run-time  data 
structures.  This  is  also  a  convenient  display  screen  from  within 
applications.  The  MUDDLE  debugging  system  provides  all  the 
usual  tools,  such  as  stopping  execution  at  marked  positions, 
invocations  or  invariant  violations:  state  examination:  tracing 
execution  and  single  stepping.  A  static  knowledge  basechecker 
is  also  provided  to  spot  inconsistencies  between  an  object's 
declaration  and  applications  before  compilation. 

4.  THE  NEED  FOR  ENHANCEMENT 

Although  initial,  smaller  systems  built  with  Muse  on  Sun  3 
machines  had  proven  fast  enough,  as  more  complex  systems 
were  developed  by  ourselves  and  other  Muse  users  it  became 
apparent  that  single  machine  performance  would  not  be  adequate 
for  full  scale  real  time  embedded  applications.  At  first  we  hoped 
to  solve  this  by  splitting  systems  over  multiple  machines  on  a 
network,  or  by  improving  hardware  performance  (i.e.  moving  to 
SPARC),  but  this  just  gave  a  reprieve  from  the  problem.  We 
realised  that  for  full  MM  application  solutions,  multiple 
high-performance  processors,  preferably  closely  coupled, 
would  be  the  best  solution.  Thus,  the  first  decision  to  take  was 
how  to  split  the  Muse  environment  over  multiple  processing 
areas. 

Low  level  parallelism  was  considered  briefly.  The  finer  gram 
option  was  to  implement  a  parallel  version  of  the  RETE  match 
algorithm  (an  efficient  implementation  of  the  matching  task  for 
a  production  rule  system)  after  [  1  ].  At  a  slightly  higher  level,  the 
development  of  a  true  concurrent  object-oriented  language  with 
a  single  object  space  and  implicit  load  balancing  and  scheduling 
was  the  second  opnon.  Work  of  this  nature  includes  ABCL/l  {2J, 
Concurrent  Smalltalk  [3]  and  REKURSIV  [4], 

Both  of  these  approaches  are  high  risk,  requiring  major  rewrites 
to  the  core  of  Muse.  In  addition,  the  concurrent  objects  system  is 
probably  unsuited  to  the  development  of  MM  systems.  This  is 
because  it  removes  the  notion  of  processor  and  process  and  could 
encourage  inefficient  design  when  implemented  on  the  limited 
inter-process  bandwidth  systems  likely  for  MM.  However,  the 
lower  risk  design  proposed  below  allows  the  first  option  to 
remain  as  a  possibility  for  subsequent  development. 

This  left  higher  level  parallelism  as  the  solution  of  choice,  given 
earlier  success  with  speeding  up  Muse  applications.  Muse  would 
need  to  provide  support  for  the  design  of  efficient  parallel 
implementations  of  MM  tasks,  so  the  vanous  design  metaphors 
available  and  then  applicability  were  examined. 

5.  METAPHORS 

In  the  real  world,  groups  of  people  work  on  lafge  and/or  complex 
tasks.  There  exist  vanous  ways  of  organising  their  work,  and 
these  real  world  systems  have  provided  “metaphors”  for 
organising  distributed  AI.  Lesser  &  Corkill  (5]  classify  these 
metaphors  along  two  dimensions.  The  first  is  related  to  the  level 
of  data  uncertainty  in  the  problem,  from  completely  accurate  to 
functionally  accurate  (uncertain).  The  second  indicates  the  level 
of  control  uncertainty,  i.e.  what  individual  processes  should  be 
doing  and  what  results  they  share,  from  nearly  autonomous  to 
cooperative.  Thus  there  are  Functionally  Accurate.  Cooperative 
(FA/C).  Completely  Accurate.  Nearly  Autonomous  (CA/NA). 
Funcnonally  Accurate.  Nearly  Autonomous  (FA/NA)  and 
Completely  Accurate.  Cooperative  (CA/C)  systems.  However. 
Lesser  and  Corkill  point  out  that  most  systems  would  be 


classified  as  either  FA/C  or  CA/NA  because  the  presence  of 
control  or  data  uncertainty  tends  to  exacerbate  the  other. 

Under  these  headings,  there  are  a  number  of  specific  metaphors. 
The  Contract  Net  Protocol  [6]  and  the  Ops  Room  metaphor  [7] 
fall  squarely  under  CA/NA  while  Multi  Stage  Negotianon  [8] 
uses  the  Contract  Net  Protocol  for  initial  negotianon  but  the 
subsequent  rounds  are  claimed  to  give  an  overall  flavour  of  the 
FA/C  approach. 

The  following  sections  describe  each  metaphor  in  more  detail 
and  examine  their  relevance  to  the  MM  task. 

S.I  F unctionallv  Accurate,  Cooperating  Systems 

Lesser  and  Corkill  produced  the  above  classificanons  of 
distributed  systems  dunng  their  research  to  apply  the  potential 
benefits  of  distributed  compunng  more  widely,  i.e.  to  systems 
that  were  not  easily  translatable  to  CA/NA  (such  as  distributed 
databases  and  process  control).  Tasks  such  as  sensor  fusion,  air 
traffic  control,  power  network  control  and  those  involving 
mobile  robots  require  nodes  to  work  on  possibly  incomplete, 
incorrect  and/or  inconsistent  data.  These  tasks  are  also 
characterised  by  their  expressabihty  as  search  processes  which 
require  multiple  local  partial  decisions  to  guide  searches,  which 
have  a  number  of  paths  to  adequate  solutions  and  which  operate 
at  multiple  levels  of  abstraction. 

It  is  their  contention  that  having  multiple  nodes  work  on  different 
parts  of  a  problem  and  share  their  local  hypotheses  with  each 
other  exploits  the  latter  set  of  characteristics  to  overcome  the 
former.  Nodes  must  therefore  be  able  to  detect  inconsistencies 
in  other  nodes’  hypotheses,  integrate  consistent  hypotheses  and 
use  these  results  to  refine  their  partial  solutions.  Experimentation 
has  indicated  that  nodes  should  share  higher  rather  than  lower 
level  hypotheses  and  that  it  is  useful  to  share  control  information 
about  a  node's  state  to  avoid  duplication  of  effort. 

Since  Knowledge  Based  Systems  are  usually  associated  with 
problem  solving  in  the  presence  of  inconsistent,  incorrect  and/or 
incomplete  data.  Durfee.  Lesser  and  Corkill  [9]  have  explored  the 
use  of  the  knowledge  based  Hearsay  II  architecture  [10], 
developed  for  speech  recognition,  within  nodes.  This  has  the 
necessary  stiucture  to  work  atdiffere.'.t  levels  of  abstraction  in  a 
data  directed  hypothesize  and  test  search.  In  applying  a  three 
node  version  of  the  original  Hearsay  II  to  connguous  fragments 
of  speech  a  60%  speedup  was  achieved  over  a  single  node 
version  Although  the  same  results  could  be  achieved  more 
efficiently  with  a  60%  faster  processor,  a  more  significant  result 
was  that  performance  degraded  gracefully  with  up  to  50%  of 
inter-node  messages  (i.e.  shared  hypotheses)  being  lost.  This 
supports  FA/C's  ciaimed  ability  to  overcome  the  problems  of 
incomplete  data. 

The  Hearsay  II  architecture  (with  different  knowledge  from  the 
speech  recognition  version)  was  used  in  a  multi-node 
architecture  forming  the  Distributed  Vehicle  Monitoring  Testbed 
(DVMT).  A  number  of  vehicles  move  over  a  geographical  are* 
There  are  a  number  of  sensors  over  the  area  and  each  is  monitored 
by  a  computing  node.  Each  node  can.  therefore,  monitor  partial 
vehicle  tracks.  The  intention  is  to  provide  a  picture  of  vehicle 
traffic.  This  is  achieved  by  having  nodes  share  hypotheses  and 
local  goals.  The  testbed  allows  variation  of  sensor  overlap  and 
level  of  hypothesis  exchanged.  In  this  case  the  levels  are  raw 
sensor  data,  groups  of  related  signals,  collections  of  groups 
related  to  one  vehicle  type  and  patterns  of  groups  to  idennfy 
vehicle  formations.  It  was  work  with  the  DVMT  that  indicated 
high  level  hypotheses  and  local  goals  (states)  should  be 
exchanged  to  improve  performance  [9], 
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The  speech  recognition  and  PVMT  experiments  could  be 
classified  as  one-  and  two-dimensional  sensor  fusion.  They  have 
had  sufficient  success  to  suggest  that  FA/C  would  be  a  productive 
approach  for  the  three-dimensional  sensor  fusion  required  for 
the  Situation  Assessment  task  of  MM. 

5.2  The  Contract  Net 

This  is  a  communication  protocol  with  application  to  dynamic 
task  allocation.  A  manager  node  broadcasts  a  task  announcement 
to  contractor  nodes.  This  contains  a  node  eligibility 
specification,  an  abstract  description  of  the  task  and  required  bid 
lormats.  This  broadcast  may  be  limited  to  a  subset  of  nodes  or 
even  a  single  node.  There  is  a  fixed  time  window  in  which  nodes 
should  bid  for  the  work.  The  received  bids  are  assessed  by  the 
manager  and  a  contract  awarded.  Bid  processing  is  application 
specific,  using  strategies  such  as  accept  the  bid  requiring  least 
information,  or  the  first  bid  to  arrive.  Similarly,  contract  nodes 
have  an  application  specific  task  acceptance  strategy.  The 
winning  contractor  then  performs  the  task.  Information 
messages  are  used  for  general  communication  between  manager 
and  contractor  and  results  are  available  through  mtenm  and  final 
reports.  The  contractor  may  also  Subcontract  out  portions  of  the 
task. 

The  key  to  use  of  this  metaphor  is  devising  a  common  inter-node 
language  for  bids  which  allows  efficient  exchange  of  information 
for  task  descriptions.  This  reduces  the  potential  problem  of 
message  overhead.  The  presence  of  bid  deadlines  means  that  it 
is  suited  to  real  time  operations  where  desired  system  response 
times  are  known,  provided  that  the  message  overhead  problem 
can  be  solved. 

Smith  [5]  gives  the  example  of  a  distributed  sensing  system 
which  consists  of  a  collection  of  sensor  and  processor  nodes 
spread  over  a  relatively  large  geographic  area.  It  attempts  to 
construct  and  maintain  a  map  of  vehicle  traffic  in  the  area. 

In  this  application,  the  processor  nodes  are  assumed  to  have 
extensive  signal  processing  capabilities  but  no  sensors,  while  the 
reverse  is  true  for  the  sensor  nodes.  Therefore,  one  situation 
requires  the  processor  node  to  announce  tasks  to  receive  sensor 
data.  The  eligibility  will  require  that  a  node  is  located  within 
some  geographical  area  and  has  certain  types  of  sensor.  The  bid 
specification  will  require  the  sensor  node's  exact  location  as  an 
entry.  The  task  abstraction  gives  the  type  of  task  ( in  this  example 
it  is  called  "signal")  and  the  location  of  the  manager  (processor) 
node.  (This  latter  information  could  be  used  by  the  sensor  node 
in  deciding  which  of  a  number  of  signal  task  announcements  to 
accept.)  The  manager  's  evaluation  of  the  resulting  bids  could  be 
based  on  the  proximity  of  a  sensor  node  to  an  ideal  location. 

This  example  is  similar  to  the  DVMT  of  FA/C  above,  so  the 
contract  net  might  be  considered  for  use  in  Situation  Assessment. 
However,  the  data  uncertainty  associated  with  SA  could  be 
problematic  for  a  CA/NA  metaphor.  Nevertheless,  the  explicit 
real  time  considerations  embodied  in  the  bid  deadlines  are  an 
important  feature  for  on-board  systems  if  the  message  overhead 
can  be  reduced  sufficiently. 

5.3  Multistage  Negotiation 

This  metaphor  is  used  for  planning  in  a  distributed  environment 
where  the  problem  may  be  over-constrained  i.e.  not  all 
constraints  are  satisfiable.  It  enables  nodes  with  a  limited 
communicauon  bandwidth  and  no  centralised  control  to  acquire 
knowledge  about  the  effects  of  a  local  activity  on  non-local  state 


and  to  modify  their  behaviour  accordingly.  Nodes  initially 
perform  local  planning  and  undergo  a  single  phase  of  Contract 
Net  negotiation  where  they  announce  tasks  related  to  furthering 
their  local  plans.  After  this  phase,  each  node  has  a  set  of  ordered 
plans  to  achieve  its  local  partial  goals.  Subsequent  rounds  of 
communication  are  toconfirm  that  its  choices  do  not  conflict  with 
those  of  other  nodes.  Conflicts  cause  a  node  to  reevaluate  its  set 
of  plans  and  to  seek  conftrmanon  of  these  new  altemanves. 
Termination  of  the  negotiation  can  be  globally  implemented  by 
token  passing,  or  over  constrained  problems  can  be  terminated  in 
a  diffuse  manner  with  local  nodes  performing  an  "irrevocable” 
commitment  of  resources,  usually  if  a  node  finds  itself  retracting 
and  reinstating  a  plan  with  no  new  data  appearing. 

The  example  application  is  maintaining  point-to-point  computer 
communication  circuits  in  a  simplified  wide  area  “backbone” 
network.  Each  node  is  responsible  for  a  geographic  area  which 
contains  a  number  of  computer  sites  and  links  between  them. 
Each  link  can  support  a  number  of  circuits.  A  problem  occurs 
when  links  involved  in  circuits  fail.  Nodes  controlling  the  area 
where  a  disrupted  circuit  terminates  perform  initial  planning  to 
idennfy  alternative  link  routing  for  that  circuit.  This  uses  the 
Contract  Net  negonauon  phase  where  task  announcements  are 
put  out  to  adjacent  nodes  asking  for  links  to  re-establish  the 
circuit.  (Note  that  nodes  are  not  aware  of  link  patterns  in  other 
areas,  nor  of  all  circuits  that  are  disrupted.)  Subsequent  rounds 
of  negotiation  verify  that  the  solutions  generated  by  the  inmal 
planning  do  not  overload  any  links. 

Tactical  Planning  is  a  major  task  in  MM.  In  a  similar  fashion  to 
the  preceding  example,  there  are  limited  resources  available  for 
plans  e.g.  time.  However,  the  plans  of  nodes  in  a  distributed 
tacncal  planner  will  probably  interact  with  every  other  node 
rather  than  those  geographically  adjacent,  so  negonauon  may  be 
more  complex  than  for  the  computer  circuits  example. 
Nevertheless.  Multistage  Negotiation  could  be  a  useful  metaphor 
for  Tactical  Planning. 

5.4  The  Ops  Room  Metaphor 

This  is  based  on  the  air  defence  ops  room  and  is  like  the  Contract 
Net  but  with  a  fixed  task  allocation  hierarchy.  Nodes  are 
responsible  for  objects  on  a  centralised  tote  board.  They  report 
to  nodes  above  them  in  the  hierarchy  and  allocate  tasks  to  nodes 
below.  The  tote  board  is  a  potential  bottle-neck  but  the  original 
problem  required  nodes  to  maintain  relatively  few  objects  on  the 
board,  each  of  which  had  a  high  semantic  content.  In  the 
language  of  the  Contract  Net.  there  was  an  efficient  common 
inter-node  language 

This  metaphor  has  obvious  application  to  ground  based  MM.  so 
it  is  worth  bearing  it  in  mind  when  deciding  on  requirements  for 
parallel  Muse 

In  summary,  both  FA/C  (including  Multistage  Negonauon)  and 
CA/NA  metaphors  (Contract  Net  and  Ops  Room)  are  potenually 
suited  to  the  MM  problem.  Muse  must  provide  the  design 
architectures  to  support  these  metaphors.  The  facilities  proposed 
in  Language  Enhancements  below  do  not  dosodirectly  (in  terms 
of  providing  task  announcement  objects  etc.)  but  the  necessary 
machinery  will  be  available  to  use  these  metaphors  with  a  small 
amount  of  additional  design  work  e  g  specifying  task 
announcement  objects.  After  describing  the  possible  methods 
forextending  Muse  towards  these  goals,  secuon  7  describes  this 
machinery  and  the  section  8  demonstrates  how  each  metaphor 
could  be  implemented  within  this  framework. 
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6.  POSSIBLE  METHODS  OF  ENHANCEMENT 

6.1  Concurrent  Objects 

These  systems  provide  a  uniform  object  space  in  which  each 
object  of  the  application  possesses  a  unique  global  reference. 
Object  access  is  equivalent  irrespective  of  where  the  request  is 
made,  and  scheduling  and  load  balancing  are  handled  as  an 
implicit  function  of  the  language.  Unfortunately,  the  uniformity 
this  brings  to  an  application  might  encourage  programming 
styles  unsutted  to  the  processor  architectures  that  are  likely  to  be 
used  in  airborne  MM  systems,  by  exhibiting  a  single  memory 
space  to  the  developer,  rather  than  reflecting  the  limitations  of 
inter-process  bandwidth.  It  would  also  involve  an  extensive 
re- write  to  Muse,  as  the  stack  based  model  of  PopTalk  is  not  ideal 
as  a  basis  for  a  concurrent  language,  and  the  performance 
penalties  of  concurrent  languages  should  also  be  borne  in  mind. 

6.2  Distributed  Rule  Systems 

Such  a  system  would  split  up  knowledge  bases  over  processes. 
To  extend  the  functionality  of  both  the  Forward  Production 
System  and  the  Backward  Chaining  System,  it  would  be 
necessary  to  support  variable  bindings  across  processes,  and 
possibly  processors.  It  would  be  necessary  for  the  BCS  to 
support  backtracking  across  process  boundaries.  This  would  in 
turn  necessitate  a  high  degree  of  coupling  between  processes,  due 
to  the  control  implicit  in  the  rule  systems,  and  would  probably  be 
better  implemented  as  a  superset  of  the  extensions  described 
above,  involving  an  extensive  Muse  rewrite.  Also,  the  metaphors 
chosen  for  MM  applications  do  not  map  well  onto  this 
architecture,  and  it  is  difficult  to  describe  its  intended  behaviour, 
either  diagrammatically  or  verbally. 

6.3  Shared  Inter-process  Databases 

The  ability  to  share  databases,  or  blackboards,  amongst 
knowledge  sources  already  exists  within  a  single  Muse  process, 
using  either  the  interests  mechanism  or  by  objects  maintaining 
references  to  individual  databases.  It  would  therefore  be  possible 
to  extend  this  so  that  each  Muse  process  could  also  access 
databases  shared  with  other  processes,  while  still  keeping  local 
databases  invisible  to  the  others.  This  would  allow  the  developer 
to  view  the  system  either  as  data  sharing  or  as  message  passing, 
by  considenng  the  database  as  a  message  slot  into  the  process, 
from  which  data  can  be  disseminated  by  using  demons  and 
production  rules. 

Conceptually,  inter-process  databases  can  be  viewed  as  a  single 
database  external  to  the  Muse  processes  that  use  it  (see  Figure  2.) 


Figure  2:  Conceptual  Implementation 


In  practice,  however,  each  process  would  have  a  local 
i  nstannanon  of  the  inter-process  database,  with  object  assertions 
being  broadcast  to  each  other  in  the  group  (see  Figure  3.) 
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Figure  3:  Practical  Implementation 
Visibility  could  be  controlled  by  defining  access  rights  of 
processes  to  databases,  such  as  read/wnte.  read  only,  etc.  Each 
process  would  hold  its  own  definitions  of  the  schemas  (objects) 
of  all  instances  the  application  intends  to  assen  into,  or  read  from, 
an  inter-process  database,  so  that  a  minimal  amount  of  data 
would  need  to  be  broadcast  to  reconstruct  an  object  asserted  by 
another  object.  It  would  also  be  necessary  to  allow  only  the 
creating  process  to  modify  or  retract  an  object,  to  remove  the 
need  for  handshaking  and  locking  funcnons.  This  would  prevent 
a  process  changing  another’s  view  of  an  object,  although  of 
course  a  process  could  make  its  own  copy  for  modification. 

TJiis  proves  to  be  a  conceptually  simple  extension  to  Muse, 
allows  the  best  support  of  the  Metaphors  suggested  above  and 
requires  considerably  less  work  to  implement  than  the  alternative 
approaches  that  were  investigated.  Therefore,  it  has  been  chosen 
as  the  architecture  for  DMuse. 

7.  LANGUAGE  ENHANCEMENTS 
The  use  of  the  current  Muse  language  over  a  distributed  system, 
supporting  the  Metaphors  described  above,  will  require  the 
addition  of  some  extra  facilities  to  the  developer.  The  following 
enhancements  have  been  put  forward  to  this  end 

7.1  Object  Broadcasting 

It  is  expected  that  there  will  be  two  parts  to  the  object  broadcast 
facilibes  essential  to  the  development  of  DMuse.  The  first  would 
monitor  assertions,  modifications  and  retractions  of  locally 
created  objects  on  the  inter-process  database  and  broadcast  them 
to  the  other  interested  processes.  It  should  be  possible  simply  to 
extend  the  current  database  access  methods  to  perform  the 
required  actions.  The  second  part  would  monitor  such  incoming 
messages  from  other  processes.  It  would  first  have  to  decide 
whether  the  broadcast  effects  a  database  it  is  interested  in.  and. 
if  so,  make  the  appropriate  changes. 

This  also  supports  the  dynamic  creation  of  inter-process 
databases,  automa:  .cally  endowing  it  with  the  necessary  methods 
for  broadcasting  event  to  other  processes  and  declaring  the 
database  to  the  system .  However,  a  mechanism  would  need  to  be 
provided  to  transfer  efficiently  an  inter-process  database’s 
contents  when  a  process  expresses  interest  in  it. 

7.2  Database  Demons 

Within  the  current  Muse,  demons  are  designed  only  to  monitor 
the  creanon  and  slot  updates  of  objects,  whether  in  or  out  of  a 
database,  and  forward  production  rules  must  be  used  to  monitor 
the  addition,  retraction  and  modification  of  objects  in  databases. 


It  has  therefore  been  suggested  that  a  "database  demon”  be 
defined,  providing  a  more  efficient  method  of  monitoring 
changes  to  an  inter-process  database. 

73  Removing  Inter-process  Databases 

If  we  are  going  to  create  inter-process  databases,  we  also  need 
to  remove  them.  This  actually  requires  three  actions.  The 
process  has  to  retract  all  objects  it  asserted  onto  the  database,  and 
broadcast  these  retractions.  It  must  remove  the  database  from  its 
list  of  monitored  inter-process  databases,  so  that  no  further 
events  for  it  are  received.  Finally,  it  must  notify  all  the  rule  sets 
and  database  demons  that  are  monitoring  events  on  the  database. 
This  means  that  the  demons  should  be  freed  for  the  garbage 
collector  and  the  database  removed  from  the  rule  set’s  interest 
slot. 

7.4  Sections 

For  us  to  be  confident  about  splitting  an  application’s  knowledge 
sources  and  allocating  them  to  separate  processors,  it  would  be 
very  useful  for  the  knowledge  sources  and  their  associated 
support  functions  to  have  been  compiled  into  sections.  Sections 
provide  a  tool  for  controlling  the  visibility  of  declaranons.  and 
are  already  supported  in  Muse,  but  without  any  support  for 
compiling  knowledge  sources  within  them.  By  allowing  this, 
knowledge  sources  are  less  likely  to  be  dependent  on  code 
defined  elsewhere  in  the  system,  and  transferring  them  between 
processors  becomes  easier. 

7.5  Application  Loading 

Loading  and  running  a  distributed  application  over  multiple 
processors,  consisting  of  many  separate  processes  -  some  written 
in  DMuse.  some  in  C  or  some  other  conventional  language  -  can 
be  a  non-tnvial  problem.  The  toolkit  therefore  requires  a  loader 
utility  that  takes  the  application  and  an  allocation  description  and 
performs  the  necessary  loading  tasks.-  including  the 
configuranon  of  communications  software  for  pu  sical  links  and 
finally  starting  the  system .  This  is  a  far  more  sigr  r  'ant  problem 
than  the  previous  single  processor  target  maclur. :  loader. 

7.6  Fault  Recovery 

Since  DMuse  is  specified  for  use  in  real-time  embedded  systems 
for  avionic  MM,  some  form  of  software  fault  recovery  -  other 
thanhardwaremulnple  redundancy  -  should  be  included.  Should 
a  processor  fail,  it  is  not  plausible  to  restart  the  enure  system,  and 
re-allocate  processes.  However,  the  proposed  architecture  does 
offer  a  means  of  recovering  all  of  the  external  data  that  was 
visible  to  the  now  dead  process.  It  should  therefore  be  possible 
to  restart  this  process  on  a  spare  processor,  or  the  least  loaded 
processor  in  use  and,  using  its  list  of  inter-process  databases, 
request  the  necessary  data  to  be  broadcast  to  it.  Providing  this 
imnal  list  is  the  same  as  that  in  use  as  the  point  the  original  process 
died,  this  should  allow  the  system  to  degrade  gracefully  rather 
than  being  destroyed.  Given  such  an  addition  to  the  architecture, 
a  process  which  is  cnncal  to  the  welfare  of  the  entire  application 
need  only  deposit  internal  data  regularly  with  a  process  on  a 
separate  processor  to  be  sure  of  its  ability  to  continue  after  a 
failure.  Such  a  depository  might  be  a  dedicated,  but  otherwise 
passive.  C  process  that  behaves  like  an  inter-process  database, 
making  the  entire  system  more  resilient. 

8.  METAPHORS  IN  DMUSE 

This  section  describes  how  the  various  metaphors  for  MM  could 
be  implemented  using  the  proposed  software  enhancements  of 
DMuse. 


8.1  FA/C 

Nodes  that  can  communicate  with  each  other  have  shared 
databases.  Hypotheses  are  broadcast  simply  by  insemng  them  in 
this  database.  At  the  local  recipient  level,  nodes  can  monitor  the 
insertion  of  hypotheses  by  using  demons  or  production  rules. 

8.2  CA/NA 

For  this  class  of  metaphor,  nodes  usually  transmit  data  and  wait 
for  a  response.  Again,  a  shared  database  would  have  the  message 
inserted  in  it  and  the  rec  ipient  would  use  demons  or  rules  to  detect 
it.  However,  the  original  sender  would  have  to  explicitly  suspend 
its  activity  rather  than  implicitly  waiting  for  the  response  to 
appear  in  the  database. 

8.2.1  Contract  Net 

This  require;,  a  database  shared  by  a  i  nodes  for  contractor-wide 
broadcasts.  The  imnal  task  announcement  is  inserted  into  the 
database  by  the  manager  and  the  contractors  then  reply  by 
inserting  their  bids  in  the  same  database.  Upon  award  of  a 
contract,  the  manager  and  contractor  can  set  up  their  own  shared 
database  for  subsequent  direct  communication. 

An  advantage  of  this  implementanon  is  that  contractors  can  see 
whether  or  not  they  won  the  contract  as  soon  as  it  is  awarded.  A 
less  useful  divergence  from  the  protocol  is  that  managers  cannot 
broadcast  to  a  subset  of  contractors  unless  private  databases 
already  exist,  although  since  the  number  of  DMuse  processes  is 
expected  to  be  stanc.  a  filter  field  could  be  added  to  the  task 
announcement  to  overcome  this. 

8.2.2  Ops  Room 

Tins  is  similar  to  the  contract  net  in  that  there  is  a  database  shared 
by  all  nodes  -  the  tote  board.  It  differs  because  the  nodes  are 
organised  in  a  hierarchy  with  one  database  shared  between  a 
parent  and  all  its  children.  The  static  number  of  DMuse  processes 
is  not  a  problem  here  since  the  hierarchy  is  also  static  for  all 
run-nme. 

83  Multistage  Negotiation 

This  uses  the  Contract  Net  metaphor  for  the  initial  phase,  which 
is  supported  as  described  above.  However,  the  lack  of 
contractor-subset  broadcasting  is  probably  not  a  problem  here 
since  subsequent  rounds  of  negotiation  with  specific  sets  of 
nodes  may  be  required.  The  sets  will  be  known  at  design  nme  e  g. 
nodes  communicate  with  others  in  geographically  adjacent  areas 
in  the  computer  circuit  example.  Thus  the  required  extra 
databases  can  be  specified  in  the  design. 

9.  DEVELOPMENT  TOOL  ENHANCEMENTS 
No  matter  how  good  the  Muse  toolkit  itself  might  be.  without  a 
sophisticated  development  interface  it  is  unlikely  to  be  used  to  its 
full  extent.  The  current  tools,  described  above,  have  proven  very 
useful  for  developing  single  threaded  applicanons.  but  the  shere 
size  and  complexity  of  MM  applicanons  are  likely  to  entail 
muinple  developers  as  well  as  processes  and  processors.  It 
should  also  be  noted  that  debugging,  in  a  non-determmisnc 
distributed  environment,  of  multiple  processes  and  processors,  is 
considerably  more  complicated  than  debugging  a  single  process. 
The  following  enhancements  have  been  proposed. 

9.1  The  Structured  Editor 

Support  for  muinple  development  streams,  requiring  the 
integranon  of  the  work  of  separate  individuals  as  they  complete 
(heir  parts  of  the  application,  suggests  that  the  current  Muse 
method  of  anonymous  "Am"  files  is  inadequate.  Instead  the 
DMuse  structured  editor  should  be  supplied  with  a  set  of  module 


26-6 


pointers  (file  names)  to  be  built  into  the  application  when  the 
editor  is  invoked.  Each  developer  can  then  modify  their  own 
code  as  with  the  current  stnictured  editor,  and  when  the  session 
is  terminated,  their  source  is  written  out  in  a  format  that  can  be 
referenced  by  other  developers.  The  UNIX  sees  source  code 
control  mechanism  could  also  be  used  at  this  level  to  provide  a 
development  backtrace  and  logging  mechanism. 

9.2  The  Browser 

The  current  Browser  works  with  the  same  structured  folding 
editor  technique,  but  displays  objects  from  within  a  Muse 
application.  For  DMuse.  many  of  the  objects  assigned  to 
inter-process  databases  will  have  been  created  in  other 
processes,  and  so  viewing  would  have  to  cease  where  the  value 
referenced  into  another  process.  The  DMuse  browser  should 
therefore  have  the  ability  to  follow  these  references. 

These  values  are  based  on  a  snapshot  of  the  object’s  value  at  the 
moment  the  display  was  initiated.  Displaying  complex  data 
structures  can  be  computationally  expensive,  since  it  has  to  create 
a  proportionately  sized  data  file.  To  achieve  greater  efficiency, 
alternative  browsing  methods  should  be  supported.  These  would 
include  lazy  evaluation  -  only  updating  the  value  of  a  slot  when 
its  fold  is  opened,  and  re-evaluating  only  when  demanded 
(possibly  by  closing  and  opening  the  fold  again)  -  and  dynamic 
updating  -  re-displaying  the  value  whenever  it  changes. 

The  DMuse  browser  should  also  have  thecapability  of  displaying 
objects  from  different  processes  and  processors  in  multiple 
windows,  as  well  as  allowing  folds  in  one  window  to  be  opened 
into  another. 

9 3  The  Debugger 

The  current  system  only  allows  trips  (break  points)  to  be  set  on 
rules.  Within  DMuse  this  should  be  extended  to  all  runnable 
objects,  and  therefore  also  requires  the  browser  to  be  able  to 
display  these  objects,  including  procedures  and  methods.  Trips 
should  also  be  able  to  halt  one  or  more  processes  as  soon  as  is 
practicable,  allowing  the  developer  to  examine  a  frozen  system. 

Single  stepping  also  becomes  a  problem  in  DMuse.  as  it  needs  to 
follow  execution  across  process  boundaries  so  that  the  developer 
can  watch  the  effects  of  an  event  across  a  distributed  application. 
It  should  also  be  possible  to  single  step  processes  affected  by  a 
single  event  independently  of  each  other.  The  ability  to  indicate 
the  current  tripped  point  in  a  source  display  should  also  be 
included. 

10.  HARDWARE  EVALUATION 
It  was  decided  at  an  early  stage  of  this  research  that  we  would 
concentrate  on  Reduced  Insmichon  Set  Computer  (RISC) 
architecture  machines.  This  was  due  to  the  increased 
performance  they  provide  and  the  even  greater  increases  in 
performance  that  they  promise  over  Complex  Instruction  Set 
Computers  (CISC),  such  as  the  Intel  80486  and  Motorola  68040. 
The  sort  of  features  generally  found  in  RISC  processors  are: 

*  All  machine  instructions  are  executed  in  a  single  processor 
cycle  -  there  is  no  micro-code. 

•  The  processor  recognises  far  fewer  and  simpler  instruenons 
than  a  CISC,  hence  the  name.  This  doesn't  prove  too  great 
a  problem,  as  research  shows  that  80%  of  software  uses  only 
these  simple  instructions  and  the  speedup  produced  by  not 
having  to  decode  micro-code  easily  makes  up  for  the  extra 
time  spent  running  multiple  instructions  for  a  more  complex 
task. 


•  Operations  are  only  earned  out  on  registers,  with  memory 
only  accessed  for  loads  and  stores. 

•  Instructions  come  in  a  fixed  length  format.  This  simplifies 
the  fetch/execute  cycle  and  the  supponmg  hardware. 

•  The  processor  has  a  large  register  set  and/or  ‘register 
windows’  to  improve  compiler  efficiency.  This  allows 
procedure  calls  to  have  their  own  set  of  registers,  usually 
with  some  overlapping  with  the  previous,  calling  procedure 
to  pass  data  between  them,  a  local  set.  and  some  shared  with 
called  procedures. 

•  Memory  fetch  pipelines  and/or  cache  memory  areemployed 
so  that  fast,  single  cycle  processors  can  be  used  with  slow 
main  memory. 

RISC  processors  are  also  generally  more  reliant  on  software 
support  tools  than  CISC  for  several  reasons: 

•  The  reduced  functionality  of  the  RISC  instiucuon  set  means 
that  coding  in  assembler  is  far  more  difficult  and  compilers 
are  more  necessary. 

•  Many  functions  that  are  removed  from  the  instruction  set  are 
still  used  commonly  enough  that  they  must  be  replaced  with 
optimised  library  functions.  RISC  processors  are  often 
supplied  with  libraries  for  functions  for  integer  multiply  and 
divide  or  array  access,  for  instance. 

•  Some  features  of  the  RISC  processor  can  only  provide 
performance  enhancements  if  they  are  utilised  correctly  by 
a  compiler.  Examples  of  this  are  register  windows,  which 
must  be  mapped  onto  procedure  calls  and  delayed  branches, 
which  can  improve  pipeline  performance.  Superscalar 
architectures,  which  allow  each  separate  section  of  the 
processor  to  operate  in  parallel,  require  instructions  to  be  fed 
to  U  in  groups  of  one  for  each  part  to  achieve  optimum 
performance. 

Most  RISC  compilers  also  contain  optimisation  techniques 
designed  specifically  for  then  target  processor,  a  process  which 
is  harder  to  develop,  and  so  slower  to  appear,  on  CISC  platforms. 

The  evaluation  of  both  the  above  software  enhancements  and  of 
the  possible  target  machine  architectures  was  undertaken  as  a 
study  contract  ending  in  Apnl  1900.  Although  the  decisions 
reached  about  any  changes  to  the  Muse  system  would  remain 
esenhaliy  stable,  it  was  noted  when  the  contract  started  that  the 
m  teleprocessor  market  place  was  so  volatile  that  any  conclusions 
might  immediately  be  invalidated.  For  this  reason  it  was  decided 
to  compare  each  processor  on  how  its  architecture  supported  the 
Muse  virtual  machine  model,  and  the  level  of  performance 
expected  for  Muse  on  each  processor  running  at  equal  clock 
speeds.  This  last  part  required  some  normalisation  of  the 
benchmarked  figures  which,  since  they  took  into  account  only 
clock  speed  and  not  memory  speed,  bus  bandwidth  or 
co-processor  performance,  was  not  particularly  ideal. 

However,  the  Hemes  and  Jalics  benchmarks  [11]  described 
below  and  used  here  were  implemented  with  loops  of  small 
sections  of  sequential  code  which,  if  able  to  fit  into  the 
processor's  cache,  gave  it  a  great  advantage  as  it  had  no  need  to 
make  external  memory  references.  Once  the  cache  size  is 
exceeded  the  performance  loss  becomes  very  evident  as  the 
external  memory  reads  take  up  more  ume.  Muse  is  a  very  large 
program  that  seldom  operates  sequentially  when  it  is  interpreting 
Poptalk  code,  and  so  where  some  processors  might  have  this 
advantage  with  the  benchmarking,  it  probably  would  not  be 
reflected  with  Muse  itself.  Since  the  Muse  program  used  for  the 


benchmark  was  a  data  fusion  example,  which  read  new  data  on 
each  iteration,  a  data  cache  was  ineffective.  Also  affecting  this 
is  the  size  of  the  instruction  pipeline,  since  it  must  be  flushed  at 
a  context  switch  -  the  longer  the  pipeline,  the  longer  it  takes. 
Despite  all  this,  we  do  believe  we  were  able  toestimate  with  some 
accuracy  the  expected  performance  of  Muse  on  each  processor. 

The  Heines  and  Jalics  Benchmarks  were  chosen  for  their  ease  of 
porting  and  highly  detailed  output  on  the  performance  of  each 
different  type  of  C  insmicnon.  Rather  than  relying  on  only 
computation-intensive  tasks  or  •synthetic'  benchmarks  that  try 
to  include  a  typical  instruction  mix  from  a  range  of  applications, 
these  tests  measure  cycle  times  over  a  set  of  more  than  400 
common  C  ‘instructions ’ .  This  is  achieved  by  measuring  the  time 
taken  to  execute  the  smallest  components  of  a  high  level  language 
program,  averaged  over  thousands  of  repetitions  of  a  single 
fragment  of  C  code.  The  Heines  and  Jalics  suite  also  includes  a 
set  of  1 2  more  commonly  used  benchmarks  for  comparison,  such 
as  Dhrystone.  Quicksort.  Sieve,  etc.  Some  care  is  taken  toensure 
that  optimising  compilers  don't  remove  these  pieces  of  code  as 
redundant,  which  would  result  in  zero  run  times.  The  advantage 
of  all  this  is  that  the  result  is  not  a  single  figure,  but  rather  a 
complete  set  of  diagnostic  tables  that  can  be  used  to  asses  and 
compare  particular  compiler/processor  combinations. 

Using  normalisation  proved  to  be  a  wise  decision,  however,  as 
nearly  all  the  processors  compared  have  since  been  superseded 
by  better  and  faster  models.  The  problems  of  finding  board  level 
products,  and  the  necessary  software  for  Muse  to  be  ported  to  and 
to  run  on  have  also  in  most  cases  been  alleviated  since  then.  Even 
so  the  results  given  for  the  SPARC  processor  are  now  not 
particularly  relevant,  as  the  SPARC  design  is  being  manufactured 
by  various  different  companies  using  different  techniques. 
Current  versions  include  a  super-scalar  implementation,  which 
implies  that  more  than  one  instruction  will  be  being  processed  per 
cycle  -  as  the  i860  already  does  -  and  this  would  therefore  not 
produce  figures  in  line  with  the  benchmarked  SPARC  for  its 
respective  clock  speed.  Equally,  MIPS  are  now  about  to  release 
the  R6000,  which  uses  a  compatible  instruction  set  but  adifferent 
architectural  design. 

For  this  reason  we  will  not  enter  into  the  results  in  any  great  detail, 
but  will  instead  try  to  explain  why  the  architecture  chosen  was 
considered  better,  for  our  use.  than  the  others  tested. 

11.  PROCESSOR  ARCHITECTURES 

The  processors  chosen  for  evaluation  were  the  Sun  SPARC,  the 
MIPS  R2000,  The  Intel  i860,  the  Motorola  88000  and  the 
Advanced  Micro  Devices  Am29K.  We  will  first  discuss  the 
specification  of  each,  and  how  this  relates  to  porting  Muse  to  it. 
A  description  of  the  processor  architecture  is  then  given, 
followed  by  areview  of  available  products  for  our  use  at  the  time. 
An  overview  of  the  position  of  each  in  the  RISC  processor 
commercial  marketplace  is  also  given  as  a  pointer  to  likely  future 
developments.  They  were  compared  to  the  “standard"  Muse 
system  running  on  a  SUN-3  machine  using  a  Motorola  68020  at 
20Mhz,  and  all  run-times  were  calculated  as  a  percentage  of 
those  measured  on  it.  The  timing  figures  are  given  later. 

11.1  The  Intel  i860 

The  benchmarked  system  used  was  a  plug  in  accelerator  card  for 
an  IBM  PC  compatible  machine  called  the  “star860”  using  an 
i860  running  at  33Mhz.  This  was  the  highest  clock  speed  tested, 
and  so  gave  it  a  disadvantage  in  the  normalisation  process.  The 
C  cross  compiler  supplied  was  ANSI  rather  than  System  V 
compliant,  and  did  not  include  sufficient  support  to  port  Muse  to 


it  for  testing.  The  other  benchmarks  were  run.  however,  and  very 
good  results  were  achieved  (see  Figure  4  below.) 

The  processor  itself  seems  to  be  RISC  only  in  name  when 
compared  with  the  others  here,  as  although  it  has  a  reduced, 
simple  instruction  set  it  is  extremely  complex  in  design.  The 
mam  difference  is  that  it  is  super-scalar,  allowing  it  to  use  the 
integer  maths  unit,  the  floating  point  unit  and  the  memory 
handling  unit  in  parallel  and.  as  such,  could  execute  three 
instrucuons  at  once.  This  would  require  it  to  be  fed  an  instruction 
each  of  the  integer,  floating  point  and  load/save  types  in  a  row, 
but  a  compiler  opumised  for  it  could  make  that  more  likely  than 
it  might  at  first  appear.  Intel  suggest  a  sustainable  one  and  a  half 
instructions  per  clock  cycle.  A  small  cache  for4K  of  instrucnons 
and  8K  of  data  is  provided  on-chip,  but  this  is  too  small  to  be  of 
much  use  to  Muse,  and  its  presence  means  that  board  designers 
would  be  unlikely  to  include  a  larger  secondary  one.  It  also  uses 
a  three  stage  pipeline,  and  includes  hardwired  Z-buffering  and 
some  complex  graphics  instnicoont.  The  benchmarks  showed 
that  it  was  credibly  fast  at  floating  point  operations  and  carrying 
out  function  calls  (context  switching). 

Although  all  these  technical  achievements  makes  for  a  very  fast 
and  efficient  piece  of  silicon,  it  also  makes  scaling  the  design  far 
more  difficult  -  a  problem  when  this  is  the  only  possible  design. 
One  of  the  advantages  of  simply  designed  RISC  processors 
comes  from  the  physics  of  the  components  and  lines  placed  on 
the  chips  surface.  The  smaller  they  get  the  less  resistance  they 
have,  signals  navel  faster  and  have  less  distance  to  travel,  and 
they  dissipate  less  heat.  This  allows  the  processor  to  be  clocked 
faster,  as  each  signal  can  be  expected  to  have  reached  all  of  the 
components  before  the  next  is  sent,  and  there  is  less  worry  of  heat 
damage  or  heat  generated  errors.  The  only  limitation  to  this 
shrinking  effect  comes  when  the  lines  get  so  close  together  that 
electrons  manage  to  “tunnel”  between  them.  The  MIPS  and 
SPARC  processors  have  both  been  able  to  use  this  to  great  effect 
-  Sun  quote  a  doubling  in  performance  every  16  months  so  far 
and  for  the  foreseeable  future  -  but  after  nearly  three  years  Intel 
have  only  just  been  able  to  announce  a  new  version  of  the  i860 
that  runs  at  50Mhz.  Further  increases  might  be  possible,  but  not 
with  the  ease  of  the  simpler  designs. 

Intel  was  the  first  company  to  produce  microprocessors,  but  the 
i860  was  their  first  attempt  at  a  RISC  architecture,  coming 
noucably  later  than  their  competitors.  Although  some  machines 
have  been  based  on  it.  it  has  been  used  mostly  as  an  acceleration 
option,  particularly  in  graphics  systems.  Intel  has  also  produced 
the  i960,  with  a  smaller  package  and  pin  count,  achieved  by 
shaving  off  some  functionality  and  cache  size,  aimed  at  the 
embedded  systems  market.  At  the  time  of  benchmarking  there 
were  three  i860  and  four  i960  board  level  products.  Judging  by 
the  court  action  in  late  1990  between  Intel  and  AMD  over  the 
latter’s  80386  compatible  processors,  we  cannot  expect  to  ever 
be  able  to  second-source  these  processors. 

11.2  The  Motorola  88000 

This  processor  was  also  tested  as  an  accelerator  board  for  an  IBM 
PC  compatible,  which  in  this  case  was  an  Opus  board  running  at 
25Mhz.  It  had  quite  a  small  cache,  but  ran  a  System  V  Interface 
Definition  (S  VID)  compliant  implementanon  of  UNIX,  allowing 
easy  implementation  of  a  Muse  port. 

Motorola  have  designed  a  complete  chip  set  for  the  88000  senes, 
including  the  88100  processor  and  the  88200  cache/memory 
management  unit  (CMMU)  which  each  incorporate  I6K  of 
on-chipcache.  Uptotourcanbeconnectedtoeach88100.  This 
results  in  a  consistency  of  available  products  -  all  the  board  level 
implementations  on  the  market  at  the  time  of  tesnng  were 
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configured  with  the  same  cache  design.  The  design  incorporates 
a  three  stage  pipeline  and  “burst  mode"  memory  read 
capabilities,  which  allow  it  to  rapidly  read  a  sequential  group  of 
memory  locations  from  ‘static  column’  dynamic  RAM.  The 
Opus  board  had  two  CMMUs. 

The  benchmarking  showed  it  to  be  fast  at  carrying  out  function 
calls  and  on  floating  point  calculations.  but  slow  at  referencing 
16-bit  data  and  pointer  dereferencing.  This  last  point  is  a  major 
disadvantage  for  Muse  execution.  It  also  showed  poor 
performance  when  comparing  data  types  -  being  between  four 
and  six  times  slower  than  the  others. 

Like  the  SPARC  and  MIPS  processor,  the  88000  has  the  backing 
of  a  group  of  hardware  and  software  manufacturers  touting 
themselves  as  an  “Open  Systems”  group.  In  this  case  it  is 
880pen,  who  provide  a  specification  and  test  for  compliance  of 
their  standards.  So  far  Data  General  is  the  main  manufacturer 
beyond  Motorola  themselves  to  be  delivering  compliant 
machines  on  a  large  scale  with  its  Aviion  range,  which  does 
include  competitively  priced  multi-processor  systems  that  might 
provide  a  laboratory  based  development  system  for  DMuse. 
Encore  also  uses  them  in  their  machines.  The  88000  has  not 
enjoyed  much  success  and.  since  the  agreement  between  Apple 
Computers  Inc.andIBMCorp.mmid  1991  resulting  in  Motorola 
being  brought  in  to  build  the  single  chip  version  of  the  RS/6000. 
its  continued  existence  has  to  be  questioned.  Both  Motorola  and 
Tadpole  produce  88000  based  board  level  products,  available  in 
single  and  multi-processor  configurations  with  real-time  UNIX 
implementanons.  at  least  five  other  such  systems  also  exist. 

II J  The  AMD  Am29000 

The  benchmarked  system  was  an  evaluanon  board,  for  which 
code  had  to  be  crossed-compiled  on  a  host  machine,  running  at 
25  Mhz.  Like  the  i860 cross-compiler,  this  was  ANSI  compliant, 
and  Muse  could  not  be  potted  for  testing.  The  design  included 
a  very  small  cache.  The  benchmarks  showed  it  to  be  slow  at 
referencing  16-bit  data,  pointer  dereferencing  and  particularly 
slow  on  floating  point  operations.  A  floating  point  coprocessor 
could  be  added,  but  pointer  dereferencing  is  very  important  for 
Muse  operation.  It  also  showed  it  to  be  very  siow  at  adding  two 
numbers  referred  to  by  adouble  pointer  dereference,  whichcould 
be  either  a  compiler  fault  or  a  failure  in  the  data  pipeline 
management 

The  processor  itself  is  designed  for  use  in  cheap  embedded 
systems,  and  so  uses  slow  memory.  It  makes  up  for  for  this  by 
including  facilities  for  burst  mode  accessing  and  a  512  byte 
internal  branch  targetcache.  It  also  contains  a  four  stage  pipeline. 

The  Am29000  is  quite  an  old  chip,  and  has  seen  more  use  in 
academic  projects  and  embedded  systems  -  including  many  laser 
printers  -  than  in  commercial  workstations.  It  would  therefore 
be  quite  difficult  to  produce  a  development  system  for  Muse  on 
such  a  platform .  although  at  least  three  board  level  products  exist 
which  use  cross-compilers  and  development  tools  on  host 
systems.  AMD  themselves  are  probably  better  known  for 
producing  go-faster  versions  of  Intel ’s  80x86  range,  and  general 
purpose  PLDs,  etc.,  than  for  this  product,  and  its  future  is 
unknown. 

11.4  The  MIPS  R2000 

The  R2000  was  tested  as  part  of  a  UNIX  workstation,  the  MIPS 
RISCstation  2030.  This  version  of  UNIX  was  SVID  compliant, 
and  so  porting  Muse  and  the  benchmarking  code  was  quite  a 
simple  process.  Being  a  workstation,  it  had  quite  a  large  cache 
-  32K  data  and  32K  instrucnon.  and  the  system  was  clocked  at 


1 6  67Mhz  -  the  slowest  tested.  The  processor  also  incorporates 
a  five  stage  pipeline.  This  gave  it  quite  an  advantage  in  the 
normalisation  calculanons.  and  since  its  performance  was  so 
competitive  anyway,  suggests  the  likelihood  of  even  better 
reslults  with  later  generations  that  clock  faster.  The  benchmarks 
showed  it  to  be  fast  at  floating  point  operations  (except  floating 
point  division  -  a  problem  with  the  Floanng  Point  Unit  (FPU)), 
array  referencing  and  local  data  access.  The  results  showed  it  to 
be  fast  at  single  pointer  dereference  but  not  so  fast  with  double 
pointer  dereference,  which  suggests  either  that  the  compiler 
doesn’t  track  double  pointer  references,  or  that  the  pipeline  stalls 
on  a  pointer  to  a  pointer.  These  are  important  to  Muse  due  to  the 
structure  of  its  symbolic  data  frames. 

At  the  time  of  the  benchmarking  the  CES  RAID  8235  board  level 
system  was  about  to  be  released,  based  on  an  R3000  with  a 
real-time  kernel  and  development  support  from  a  Sun 
workstanon.  Other  such  products  are  also  available. 

The  original  M  IPS  processor  was  the  first  commercial  product  to 
use  the  academically  proven  performance  advantages  of  the 
RISC  architecture.  At  the  time  of  wnnng  this  has  been  much 
improved  upon,  and  has  been  chosen  as  the  standard  processor 
for  a  range  of  personal  computers/workstanons  backed  by 
Digital  Equipment  Corporation,  MIPS  themselves,  and  a  large 
number  of  IBM  PC  compatible  hardware  and  software 
manufacturers,  including  Compaq  calling  themselves  ACE. 
However,  Digital’s  requirements  for  their  own  system 
compatibility  mean  that  MIPS  have  to  produce  processors  with 
the  word  order  reversed  -  small-endian  rather  than  the  usual 
big-endian  -  for  them,  leaving  the  quesnon  of  compatibility  in 
question.  Also,  The  Apache  Group  has  been  set  up  to  counter 
ACE  by  AT&T  and  Unix  International.  They  have  started 
MIPS/Open  to  standardise  on  MIPS  with  Unix  SVR4  instead  of 
the  more  PC  oriented  designs  of  the  ACE  consortium. 

If  nothing  else  then,  this  suggests  a  connnued  life  for  the 
processorfamily,  and  that  a  lot  of  effort  will  be  put  intoproducing 
a  range  of  products  that  might  be  used  as  DMuse  platforms  -  the 
R6000  senes  processors  should  be  in  production  within  our 
timescale  offenng  far  greater  performance. 

11.5  The  SPARC 

The  benchmarked  system  was  a  Sun  SPARCstation  1.  which  ran 
a  20MHzclock, producing  approximately  12.5SPECmarks.  The 
benchmarks  showed  it  to  be  slow  at  integer  multiplication  - 
which  is  used  heavily  in  array  referencing.  The  SPARC  uses  a 
software  iibrary  function  for  this  while  the  other  processors 
(except  the  Am29K)  do  it  in  hardware.  However,  it  did  not  prove 
to  be  as  slow  at  integer  division,  while  the  FPU  was  unusually 
slow  on  floating  point  division.  The  result  for  sprintf  was  also 
extremely  slow  at  the  optimisation  level  used,  and  this  skewed 
the  SPARC  average  timings. 

The  first  thing  to  be  noted  about  the  SPARC  (Scalable  Processor 
ARChitecture)  design  is  that  it  is  a  book  -  an  open  specification 
which  can  be  purchased  for  the  price  of  its  pnnang  and  used  to 
produce  compliant  processors.  The  only  proviso  that  Sun  places 
on  its  licensing  is  that  they  have  first  access  to  any  new  vetsion. 
Due  to  this,  there  are  now  over  eight  chip  manufacturers  working 
on  producing  SPARC  compliant  implementations  -  each  putting 
their  own  technological  advantages  to  use  and  compenng  with 
each  other,  rather  than  producing  for  the  slightly  more  "niche” 
marketplace  of  the  general  RISC  processor.  This  means  that 
SPARCs  are  gaining  in  performance  faster  than  the  others,  and 
bringing  all  the  other  advantages  of  multi-sourcable  products, 
such  as  pricing  and  availability.  Also,  as  the  SPARC  standard  is 
increasingly  taking  over  the  RISC  workstanon  market,  the 
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number  of  products  -  both  hardware  and  software  -  available  is 
also  increasing.  Many  of  the  companies  who  have  made  their 
names  making  IBM  PC  clones  are  now  working  on  SPARC 
clones  -  most  notably  Opus  and  Compuadd.  This  gives  us  a 
wider  choice  of  platform  and  a  wider  market  for  the  final 
development  system. 

The  SPARC  speciticauon  is  for  an  integer  processor  system  only, 
with  floating  point  work  being  earned  out  by  an  external  FPU. 
Different  FPUs,  including  some  by  Weitek.  can  be  connected  for 
vanous  levels  of  performance.  It  is  possible  to  connect  more  than 
one.  and  some  of  the  more  recent  implementauons  are  designed 
with  on-chip  FPUs,  fixing  the  type  used  but  reducing 
mter-commumcauon  times.  The  SPARC  compliance  manual 
includes  definitions  of  the  memory  bus.  the  S-BUS  expansion 
connectors.  and  the  methods  of  inter-processor 
commumcanons.  There  are  no  regulations  on  the  shape,  pinout 
or  manufacturing  process,  allowing  products  to  be  developed 
using  the  most  suitable  packaging  and  substrate  materials. 
Gallium-arsoiude  and  bipolar  chips  are  being  developed.  The 
specificauon  defines  cache  size  and  a  register  window  system, 
the  last  of  which  is  useful  for  the  Muse  virtual  machine  model. 
At  the  time  of  testing  board  level  implementations  -  specifically 
the  Sun  SPARCengine  IE,  was  based  on  this  system,  but  an 
enhanced  SPARCengine  2E  is  now  available,  capable  of  over 
twice  the  performance.  Within  the  timescale  of  this  project  it  is 
expected  that  board  level  products  based  on  the  new  chip  sets 
from  Tera  Microsystems  and/or  Fujitsu  Microelectronics 
embedded  high  performance  processors  will  also  become 
available. 

At  the  time  of  writing,  Solboume  and  ICL  were  selling 
inexpensive  symmetric  multi-processor  workstations  capable  of 
running  a  DMuse  implementation,  each  running  their  own 
SUNOS  superset  to  control  the  load  balancing.  Sun  themselves 
were  discussing  a  system  using  four  Viking  processors  in  a 
workstation  box  with  their  own  implementation  of  a  load 
balancing  SUNOS,  which  they  expect  to  be  available  in  1992. 
The  Viking  processor  is  a  40Mhz.  superscalar.  BiCMOS 
implementation  being  built  by  Texas  Instruments  that  has  been 
rated  at  anything  between  50  and  80  MIPS,  depending  on  the 
usual  superscalar  compiler  techniques.  Unix  International,  the 
group  led  by  AT&T  and  Sun  in  developing  Unix  System  V 
Release  4  (SVR4).  have  stated  that  the  multi-processor  version 
ofSVR4  will  not  be  available  until  ’92/93.  Recently  the  press  has 
commented  that  Sun’s  first  multi-processor  systems,  the  Galaxy 
range,  will  only  use  asymmetric  multiprocessing  implemented 
with  a  maximum  of  two  pairs  of  40Mhz  Cypress  SPARC 
implementations  It  is  believed  that  the  Viking  based  systems 
will  be  called  "Jupiter"  and  is  currently  waiting  for  the 
completion  of  the  processors  and  a  working  operating  system  to 
run  under.  Sun  are  believed  to  be  having  a  lot  of  trouble 
producing  a  symmetric  multiprocessing  version  of  SVR4.  but 
hope  to  release  it  as  part  of  their  Solaris  2.0  system,  due  in  the 
middle  of  1992.  This  hardware/software  platform  might  make 
a  useful  laboratory  based  DMuse  development  system. 

11.6  Others 

It  should  be  noted  that  since  these  tests  were  carried  out  other 
processors  have  been  released.  These  include  the  IBM  RS/6000 
chip  set  and  the  HP/Apollo  “Snake”.  The  formercould  not  really 
be  considered  here  anyway  -  it  is  a  RISC  in  name  alone,  needing 
a  set  of  five  chips  to  form  a  working  system .  However,  IBM  have 
recently  announced  that  they  have  managed  to  mount  nine  chips 
at  substrate  level  onto  a  single  further  substrate  which  contains 
all  the  necessary  interconnects  and  reduces  the  size  and  pinout 


problems.  This  should  allow  them,  and  Motorola,  who  have  been 
named  as  a  co-manufacturer  of  this  pan.  to  stan  producing 
smaller  and  cheaper  single  package  processors  that  might  be 
viable  for  DMuse  in  a  year  or  two.  IBM’s  recent  joining  of  forces 
with  Apple  Computers  Inc.  suggests  that  some  inexpensive 
development  systems  might  become  available  from  one  or  both 
soon  after.  This  will  probably  be  too  late  to  be  worth  evaiuanng 
for  the  first  DMuse.  however.  The  HP/Apollo  processor, 
nicknamed  “Snake",  is  available  now  in  a  range  of  workstations, 
and  the  published  performance  figures  are  very  impressive. 
These  workstations  run  a  version  of  UNIX  -  HP  are  Open 
Software  Foundation  (OSF)  members  -  and  it  can  be  assumed 
that  muln-processor  versions  will  be  available  soon  if  not  now. 
It  will  have  to  be  taken  into  account  when  a  final  decision  is  made. 

12.  PROCESSOR  BENCHMARKING 
The  following  results  were  produced.  It  should  be  remembered 
that  the  performance  figures  given  are  as  a  percentage  of  the 
68020  execunon  time  normalised  for  clock  rate  -  the  smaller  the 
better.  The  estimated  Muse  figures  are  derived  from  the  Heines 
and  Jalics  results,  and  so  their  accuracy  is  compromised  by  the 
problems  mentioned  above  (see  especially  the  88000  results.) 


Processor 

Clock 

Rate 

Heines 
&  Jalics 

Muse 

Execution 

Estimated 

Muse 

68020 

20.00 

100.00 

100.00 

100.00 

SPARC 

20.00 

39.50 

38.02 

33.75 

R2000 

16.67 

26.03 

27.16 

24.91 

i860 

33.00 

33.40 

- 

27.92 

88000 

25.00 

33.41 

52.25 

33.34 

Am29K 

25.00 

40.32 

- 

38.37 

Figure  4:  Summary  of  RISC  Benchmarks 


Although  the  estimated  Muse  figure  seems  quite  accurate  for  the 
SPARC  and  MIPS  R2000 processors,  the  figure  calculated  for  the 
88000  shows  that  we  can’t  altogether  rely  on  the  estimated 
figures  for  the  i860  and  Am29K.  Of  the  actual  Muse  execunon 
tests,  we  can  see  that  the  MIPS  was  fastest,  then  the  SPARC  and 
slowest  was  the  88000.  The  Am29K  is  definitely  the  slowest 
overall,  and  we  see  no  reason  why  it  might  run  Muse  any  faster 
than  estimated.  We  can,  however,  see  some  reasons  why  the  i860 
might  actually  run  Muse  slower  than  suggested  by  the  Heines  and 
Jalics  tests.  The  processors  were  therefore  ranked  thus: 

(1)  MIPS  R2000 

(2)  Intel  i860 

(3)  Sun  SPARC 

(4)  Motorola  88000 

(5)  AMD  Am29K 

13.  COMPILER  BENCHMARKING 
As  some  RISC  manufacturers  claim  that  compiler  opnmisanon 
is  an  important  pan  of  performance,  some  tesnng  was  undertaken 
to  compare  opnmisation  techniques  for  each  processor.  Figure 
5  shows  the  resulting  percentage  speedup  on  unopnmised  code 
portions.  Since  in  many  cases  an  adverse  effect  was  seen,  both 
the  best  and  worst  test  results  from  the  Heines  and  Jalics 
sub-groups  are  given  to  indicate  how  much  nsk  there  is  in  using 
the  compilers.  These  were  the  bundled  Sun  SPARC  C  compiler: 
The  MIPS  C  compiler;  the  Green  Hills  C  compiler  for  the  i860 
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and  the  Diab  Compiler  for  the  88000.  No  such  optimisation  was 
available  from  the  Am29K  compiler.  As  can  be  seen,  the 
compilers  that  can  most  dramatically  increase  code  execution 
speed  can  also  decrease  it  considerably  if  used  indiscriminately. 
Usually  the  same  opnmisanon  techniques  that  would  be 
particularly  beneficial  to  Muse  caused  bad  floating  point  results 
from  the  MIPS  and  Sun  compilers.  However,  it  should  be  noted 
that  the  Sun  compiler  achievedsome  very  impressive  results  with 
optimisations,  and  the  new  unbundled  Sun  C  compiler  is  said  to 
produce  far  better  optimised  code  than  the  old  bundled  product. 


Processor 

Heines 
best  % 

l  Jalics 
worst  % 

Muse 

Execution 

SPARC 

68.14 

-15.39 

45.04 

R2000 

57.66 

-122.67 

25.52 

i860 

21.63 

-27.82 

- 

88000 

22.26 

3.41 

12.26 

Figure  5:  Percentage  Speedup  from  Optimisation 


14.  PROCESSOR  SELECTION 

Other  factors  had  to  be  taken  into  account  when  finally  selecting 
the  processor  to  be  used  as  a  platform  for  OMuse.  Many  of  these 
factors  are  still  varying,  and  we  will  not  make  a  final  decision 
until  we  are  actually  ready  to  make  a  purchase  and  start 
implementation.  Some  of  the  other  variables  relevant  here  are: 

•  The  development  system  is  seen  as  a  major  part  of  the 
DMuse  system.  Without  a  good  set  of  tools  to  build  and 
debug  multi-threaded  real-time  KBS  systems  their 
construction  might  be  too  laborious  to  be  worthwhile. 

•  The  level  of  effort  necessary  to  convert  Muse  to  the  new 
platform  and  build  in  the  new  enhancements  must  be  cost 
effective  for  DMuse  to  be  an  acceptable  proposal.  This 
means  taking  into  account  the  availability  of  Muse  on  each 
architecture  as  well  as  ease  of  migration  and  hardware 
construction  and  the  development  tools  available. 

•  The  operating  systems/kemels  available  on  the  processors 
for  our  use.  The  development  system  would  be  best  running 
a  flavour  of  UNIX  -  preferably  a  major  open  standard  one 
-  for  ease  of  migranon  and  use.  Only  the  MIPS  and  SPARC 
machines  ran  a  version  of  UNIX  which  supported  the 
Berkeley  Standard  Distribution  (BSD)  socket  system  which 
is  used  for  inter-process  communication  in  Muse,  for 
example.  OS  support  for  multi-processors  would  simplify 
their  use  in  implementing  and  load-balancing  separate 
Muse  tasks.  However  an  embedded/flyable  final  delivery 
system,  which  we  must  keep  in  mind  as  the  final  target  of 
DMuse,  must  be  capable  of  true  real-time  operation  - 
something  for  which  UNIX  is  not  currently  famed. 
Therefore  a  good  and  as  similar  as  possible  real-time  kernel 
should  also  be  available  for  the  processor. 

•  Although  we  are  looking  for  the  fastest  possible  processor, 
we  must  keep  in  mind  the  problems  we  will  face  when  this 
hardware  is  finally  implemented  on  board  an  aircraft.  High 
clock  speeds  are  fine  in  the  laboratory,  but  this  would  not  be 
true  in  the  electro-magnehcally  noisy  environments  they 
will  be  placed  in  -  especially  in  helicopters  -  as  higher 
frequency  circuits  are  more  susceptible  to  radiated 
interference.  We  must  therefore  look  for  processors  that  get 
as  much  done  for  as  little  clocking  as  possible  to  counteract 
this  -  in  other  words  super-scalar  designs  as  seen  in  current 
MIPS,  i860  and  SPARC  designs.  We  have  yet  to  discover 
what  this  limiting  factor  is. 


At  the  time  of  the  benchmarks  the  final  choice  of  processor  was 
left  open,  but  at  ume  of  wnnng  the  SPARC  processor  seems  to 
be  the  best  choice  for  the  development  of  a  lab.  based  DMuse 
system.  Muse  is  already  available,  and  highly  stable,  on  this 
platform,  making  it  the  most  cost  effective  solution.  The 
performance  figures  quoted  on  new  versions,  as  they  become 
available,  closes  the  performance  gap  with  the  current  Intel  and 
MIPS  offerings,  and  thereby  reduces  any  compromises  we  might 
be  making  on  pnce/performance.  The  SPARC  currently  seems 
to  provides  the  best  development  and  target  platform, 
simplifying  the  use  of  DMuse  when  finished  as  well  as  in  its 
production.  Also,  as  discussed  below,  there  is  good  availability 
of  multi-processor  workstations  with  muiti-process/threading 
control  built  into  the  operating  system  at  costs  and  time  scales 
within  the  range  expected  for  the  DMuse  contract. 

IS.  TARGET  MACHINE  SELECTION 
Three  possible  architectures  became  apparent  to  us  as  we 
approached  this  side  of  the  problem.  Our  previous  experience 
with  Muse  had  at  first  been  on  workstations,  and  recently  a 
project  entered  into  with  GEC  Avionics  Flight  Automation 
Research  Labs  (FARL)  was  made  to  deliver  acceptable  speed  by 
spreading  the  load  over  multiple  workstanons  on  an  Ethernet 
network.  We  also  had  a  previous  project  transferred  onto  a  VME 
based  single  processor  crate  which  was  strengthened  to  allow  it 
to  be  flown  on  board  a  Lynx  helicopter  owned  by  the  then  Mission 
Management  department  of  RAE  -  now  DRA  Flight  Systems. 
The  third  option  described  below  came  to  us  late  on  in  the  original 
study  contract,  when  multiprocessor  workstations  using  some  of 
the  processors  tested  above  came  onto  the  market.  None  of  the 
three  would  cause  great  problems  in  implementation  of  DMuse. 
and  so  the  only  real  values  to  be  balanced  are  those  of  cost, 
performance  and  adaptability  /  upgradabilily. 

15.1  Loosely  Coupled  Workstations 

The  work  with  GEC  on  the  Intelligent  Displays  Manager  for 
fixed  wing  aircraft  was  originally  developed  on  Sun-3  machines, 
and  to  maintain  the  necessary  performance  as  the  system  grew  in 
complexity  it  became  necessary  to  separate  out  knowledge 
sources  and  graphics  software  and  allow  them  to  communicate 
through  harness  processes  written  in  ‘C’  which  passed  messages 
between  them  using  Ethernet.  Initially  the  largest  knowledge 
base  was  placed  on  one  machine  and  the  second,  smaller 
knowledge  base  and  the  graphics  software  were  put  on  a  second. 
As  the  system  grew  it  later  became  necessary  to  move  the 
graphics  onto  a  third  machine,  but  this  was  accomplished  easily 
by  altering  the  harness  structure  in  ‘C\  showing  the  inherent 
upgradability  of  such  a  model.  The  only  limit  on  expansion  is  the 
theoretical  limit  to  the  number  of  active  machines  on  the  network. 

However,  although  developing  DMuse  to  run  on  such  a  system 
of  interconnected  workstations  (see  Figure  7)  would  provide  the 
most  cost  effective  hardware  solubon.  it  would  be  a  great 
performance  compromise,  since  Ethernet,  at  lOMbits/second.  is 
nowhere  near  as  fast  as  some  of  the  inter-processor  buses 
especially  designed  for  such  data  interchange.  It  would  also  be 
the  most  bulky  (each  being  separately  cased)  and  most  prone  to 
fault  of  the  three  systems.  Finally,  such  a  system  would  enforce 
a  local  memory  model  on  us,  as  each  processor  would  be  a 
separate  entity,  and  this  was  not  felt  to  be  acceptable. 

15.2  VME  based  Processor  Crate 

A  system  based  on  a  VME  backplane  looked  the  most  likely  at 
the  time  of  the  original  feasibility  study,  as  it  offered  the  option 
of  building  either  a  laboratory  deskside  unit  connected  to  a  host 
or  a  hardened  flyable  crate  to  be  fitted  inside  ar>  aircraft  without 
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having  to  greatly  change  the  overall  design.  Using  a  system  of 
slot-in  cards  would  also  allow  us  to  decide  on  how  many 
processors  to  include,  and  to  select  card  designs  with  on-board 
memory,  or  which  shared  a  separate  plug  in  memory  card  in  the 
crate,  or  a  mixture  of  both  (see  Figure  7.)  Although  VME  was 
designed  for  fast  bus  communication  it  is  no  longer  considered 
as  "fast"  due  to  technology's  moving  edge.  However,  some  other 
bus  design  could  be  used  should  we  go  ahead  with  this  model. 

At  the  time  of  writing  this  is  still  a  viable  opnon.  and  we  are 
keeping  an  eye  on  the  board  level  products  available  as  the 
market  grows.  Many  of  the  products  examined  in  the  feasibility 
study  provided  some  hardware  support  for  multiple  processors, 
the  most  common  being  dual-ported  memory  shared  between  the 
CPU  and  the  VME  bus.  The  only  limitation  that  has  been  noted 
is  that  as  new  models  of  processors  become  available,  offering 
greater  performance,  they  initially  get  built  into  desktop  systems 
and  only  some  time  later  make  it  out  as  embedded  versions. 
Crates  of  variable  sizes  are  available  to  allow  different  numbers 
of  slots,  and  some  boards  are  becoming  available  which  contain 
multiple  processors  on  them. 


Cheap  (£X) 
(1)  Slow 
Unftyable 
Local  Memory 


a  system  this  way  and  still  give  a  standard  model  to  the 
programmer,  it  also  doesn't  give  them  any  hints  as  to  possible 
performance  bottle-necks  in  their  design. 

Such  a  system  would  probably  be  built  with  shared  memory  but 
local  cache,  allowing  either  memory  model  to  be  used  in  DMuse. 
All  the  buses  used  in  these  designs  are  notably  faster  thana  VME 
bus.  being  in  most  cases  builtat  board  level  with  sockets  forpiggy 
back  processor  boards  to  be  plugged  in.  Both  Sun  and  Solbourne 
have  designed  buses  with  far  greater  possible  communications 
bandwidth  than  they  can  currently  possibly  use  and  allow  the 
plugged  in  processors  to  run  at  their  own  speed,  allowing  these 
processors  to  be  upgraded  by  simply  swapping  them  with  faster 
units  on  the  same  bus. 

The  ICL  DRS6000  is  not  currently  SPARC  compliant  having 
started  with  SVR4  -  a  version  of  which  they  developed  for  Unix 
International.  They  are  apparently  working  on  an  updated 
workstation  which  uses  more  than  four  processors. 

This  final  option  also  proves  to  be  the  most  acceptable  when 
viewing  DMuse  as  a  product  for  sale  to  oiher  interested  groups. 
By  building  DMuse  for  use  on  a  commercially  available  senes  of 
machines,  rather  than  providing  both  hardware  and  software,  the 
system  becomes  far  more  attracuve.  Costs  of  such  a  system  have 
not  yet  been  finalised,  but  we  believe  that  such  a  machine  with 
local  disk  and  console  to  make  it  a  stand-alone  system,  would  fit 
well  into  our  hardware  purchasing  budget  for  the  project. 
Overall,  such  a  design,  although  it  has  some  problems,  is  seen  as 
the  most  favourable. 
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VME  crate  of  CPUs 
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Figure  7:  Possible  Hardware  Configurations 


15.3  Specialised  Multiprocessor  Workstation 

Over  the  last  couple  of  years  various  companies  have  started  to 
release  workstations  using  two,  four  or  even  eight  processors 
communicating  in  the  most  part  via  specially  designed 
high-speed  buses  using  the  fastest  available  pans.  Silicon 
Graphics  offer  a  large  machine  containing  multiple  MIPS 
processors,  and  Solbourne.  ICL.  FPS  and  now  Sun  offer 
machines  based  on  multiple  SPARCs.  Sun’s  Jupiter  machine 
mentioned  earlier,  if  it  matches  expectations  upon  release,  will 
provide  probably  the  best  performance  results  for  this  type  of 
machine  to  date.  The  figure  of  four  processors  may  be  too 
limiting,  however,  and  resomng  to  network  communications 
between  multiple  such  machines,  although  possible,  might 
become  a  bottle-neck  unless  a  fast  network  is  utilised.  Due  to  the 
operanng  system  support  for  inter-process  communications  not 
differentiating  between  where  those  processes  reside  physically, 
the  design  of  DMuse  is  unlikely  to  show  any  difference  to  the 
developer  when  communications  are  being  made  over 
inter-processor  buses  or  networks.  While  this  allows  us  to  build 


16.  OPERATING  SYSTEM  SUPPORT 

Sun  has  defined  a  multi-thread  architecture  for  SunOS  [12] 
which  will  probably  be  the  main  basis  of  their  Solans  2.0 
operating  system,  incorporating  SVR4  and  a  large  number  of  Sun 
propnetary  development  and  productivity  tools,  due  for  release 
in  mid-’92.  This  would  be  the  largest  and  best  developed  and 
supported  operating  system  for  DMuse  as  a  development  system 
for  laboratory  use.  but  may  not  be  the  solution  for  embedded  use. 
Similar  operating  systems  exist  for  MIPS  mulnprocessor 
workstations.  The  problem  with  all  of  these,  however,  comes 
when  trying  to  run  real  time  systems  under  Unix.  No  matter  how 
good  a  system,  it  can’t  promise  maximum  response  times  when 
it  doesn't  know  if  Unix  is  going  to  be  executing  its  code,  or  some 
other  process,  when  an  interrupt  comes  in  Some  versions  of 
Unix,  however,  offer  real-time  facilities  Muse  also  has  the 
capability  to  be  downloaded  and  run  on  a  target  machine  without 
Unix,  and  it  would  be  necessary  to  provide  a  similar  capability 
to  DMuse.  The  feasibility  and  study  contracts  therefore  looked 
into  various  real  time  kernel  systems  and  Unix  implementations 
to  derive  some  idea  of  the  software  support  available.  The  major 
real  nme  kernels  provide  explicit  support  for  multiple  processor 
systems,  ranging  from  transparent  allocation  of  tasks  between 
processors  loan  implementation  of  TCP/IP  that  runs  over  a  VME 
backplane. 

The  products  checked  were:  LynxOS,  TP- IX.  Vx Works.  pSOS. 
VRTX.  MTOS.  PDOS.  dbxWorks  and  XRAY.  Of  these,  only 
Vx  Works  and  dbx  Works  supported  the  SPARC  and  the  Intel  i960, 
while  VRTX  was  being  ported  to  them.  None  of  them  supported 
the.  MIPS  processor  at  that  time,  although  LynxOS.  VxWorks. 
pSOS  and  VRTX  apparently  promised  this  in  the  future.  The 
Am29K  was  only  supported  by  VRTX  while  the  Motorola 88000 
was  supported  by.  or  soon  to  be  supported  by.  all  but  dbxWorks. 
Again,  this  is  a  volatile  marketplace,  and  beyond  confirming  that 
such  things  are  possible,  it  is  pointless  attempting  to  make 
decisions  on  this  level  of  product  unn  I  we  are  c  lose  to  produc  non 
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17.  CONCLUSION 

This  paper  has  shown  how  the  original  definition  and 
construction  of  the  Muse  real  time  1KBS  toolkit,  and  it’s  use.  has 
led  us  to  define  a  system  able  to  meet  the  requirements  of 
in-flight  Mission  Management,  We  had  learnt  from  previous 
experience  that  the  original  Muse  had  the  necessary  capabilities 
as  a  software  tool,  and  we  are  now  moving  towards  meeting  the 
hardware  requirements  of  a  lapge  scale  MM  problem. 

As  can  be  seen  from  our  previous  discussions  of  the  results  given 
here,  it  is  almost  impossible  to  draw  precise  conclusions  in  an 
area  as  volatile  as  the  RISC  processor  marketplace.  However,  it 
is  hoped  that  this  paper  has  shown  how  we  approached  the 
problem  of  designing  a  real  time  knowledge  based  systems 
development  environment  from  the  groundwork  already  laid  by 
previous  research  with  Muse,  and  that  a  feel  for  the  architectural 
possibilities,  in  both  hardware  and  software,  for  such  a  system 
has  been  given. 
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Summary 

The  DLR-Institute  for  Flight  Guidance  had  developed  a  new  Arrival  Traffic  Management 
System  called  COMP AS  (Computer  Oriented  Metering  Planning  Advisory  System) . 

The  system  has  been  implemented  at  the  Frankfurt  Regional  Air  Traffic  Control  Center  in 
mid  1989  and  is  in  continuous  operation  since  then. 

A  comprehensive  implementation  plan  was  developed  in  order  to  guarantee  a  smooth 
introduction  in  particular  with  respect  to  both  technical  issues  and  controller 
acceptance.  The  experience  gained  and  the  lessons  learned  during  the  implement at ion 
process  as  well  as  the  operational  results  will  be  reported. 

1 .  Introduction 

The  job  of  the  arrival  controller  is  to  transform  a  random  input  of  various  types  of 
aircraft,  from  various  directions  into  an  orderly  sequence  of  properly  separated  and 
spaced  aircraft  feeding  into  the  final  approach  path.  During  the  last  years,  DLR  (German 
Aerospace  Research  Establishment,  Institute  of  Flight  Guidance)  has  developed,  tested 
and  implemented  a  metering,  spacing  and  sequencing  function  for  the  planning  and  control 
of  the  arrival  traffic.  It  is  significant  for  COMPAS,  that  the  computer  provides 
advisories  how  to  handle  each  aircraft  in  the  system.  The  controller  is  still  in  charge 
of  the  traffic  situation,  and  is  free  to  disregard  or  modify  the  suggested  plan. 

The  computer  serves  as  an  aid  to  judgement,  but  the  functions  do  not  enter  the  primary 
control  loop  ( figure  1 ) . 


Figure  1  Planning  and  executive  functions 
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The  system  has  reached  a  particular  level  of  automation  and  complexity  especially  for 
the  functions  landing  time  prediction,  sequencing  and  spacing,  flight  control,  human- 
machine-interface  and  integration  within  the  overall  air  traffic  management  system. 

A  solution,  where  the  computer  system  works  fully  automatic,  with  the  human  controllers 
only  monitoring  the  system,  in  order  to  take  over  in  case  of  system  failure,  presently 
is  for  many  reasons  neither  practicable  nor  acceptable. 

That  is  the  reason  why  so  far  the  degree  of  automation  is  guided  by  the  philosophy  of 
giving  computer  assistance  to  the  human  controllers.  The  system  releaves  the  controllers 
of  routine  functions  and  supports  them  with  all  necessary  data  to  take  safe,  efficient 
and  orderly  control  actions.  The  decision  making  itself  however  and  thus  the  overall 
responsibility  is  still  left  to  the  controllers. 

Because  the  theoretical  background  of  COMPAS  already  has  been  described  before  (1,  2], 
there  will  be  no  further  discussion  of  the  basic  COMPAS  algorithm.  Basically,  COMPAS  is 
a  computer  controlled  planning  system  (figure  2)  which  helps  the  ATC  controllers  to  plan 
and  control  the  inbound  flow  of  air  traffic  into  the  terminal  control  area  (TMA)  of  an 
airport  more  efficiently.  The  planning  algorithm  suggests  a  landing  sequence  and 
schedule  to  air  traffic  controllers  taking  into  account  a  variety  of  constraints  and 
parameters  in  order  to  exploit  the  available  capacity  of  an  airport  in  an  optimal  way. 
Unnecessary  delays  will  be  avoided  and  unavoidable  delays  will  be  absorbed  as  early  as 
possible.  The  basic  ideas  were  tested  with  an  experimental  COMPAS  in  a  simulated  ATC 
environment  and  the  results  are  reported  in  [ 3 ] .  After  the  implemention  of  the 
operational  version  of  COMPAS  a  second  evaluation  was  carried  out  and  is  reported  in 
[<]. 


Figure  2  COMPAS  data  processing  functions 
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2.  Objective  of  the  project  COMP AS -OP 

Based  on  the  positive  results  of  the  experimental  studies  of  COMPAS  obtained  in  the 
environment  of  the  Air  Traffic  Management  and  Operations  Simulator  (ATMOS)  of  DLR  the 
project  COMPAS-OP  was  defined  in  order  to  develop  and  build  a  prototype  system  for  the 
ATC  center  at  Frankfurt/Main  (figure  3)  and  to  test  and  to  assess  this  operational 
system  under  real  ATC  conditions.  The  mathematical  planning  functions  and  the  human 
interface  of  the  experimental  system,  which  were  already  optimized  in  the  simulator 
studies,  were  used  as  a  starting  point. 


Figure  3  Frankfurt/Main  airspace  structure 

The  operational  COMPAS  system  (COMPAS-OP)  was  designed  for  Frankfurt /Main  ATC 
environment.  Eight  controller  positions,  six  for  the  Area  Control  Center  and  two  for  the 
Approach  Control  have  been  equipped  in  1989  with  COMPAS  displays  and  keyboards.  During 
the  first  half  a  year  of  operation,  the  syBtem  was  evaluated  under  real  ATC  conditions. 
Special  software  equipment  for  data  recording  and  evaluation  had  been  integrated  into 
the  COMPAS-OP  main  computer  (41. 

Due  to  the  prototype  character  of  the  current  system  the  main  computer  and  the 
supporting  subsystems  in  the  starting  phase  were  not  redundant.  In  1990  it  was  the  task 
of  an  industrial  manufacturer  to  build  a  redundant  system  according  to  the 
specifications  of  the  BFS .  For  the  construction  of  the  prototype  system  only  off-the- 
shelf  hardware  was  used.  Similarly  the  software  development  relied  on  standard  software 
libraries  readily  available. 

Although  an  evaluation  of  the  functional  capacity  and  the  operational  performance  of  the 
planning  system  remains  the  overall  objective,  a  field  test  of  an  operational  system 
will  be  necessary  in  many  ways  different  from  a  simulator  evaluation  made  at  DLR. 

The  simulator  evaluation  of  the  experimental  system  dealt  with  the  feasibility  of 
computerized  approach  planning  in  general.  It  focussed  on  the  comparison  to  conventional 
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procedures,  thereby  raking  use  of  the  exact  reduplication  of  traffic  scenarios  which  is 
only  given  in  simulation. 

Real-world  operation  does  not  offer  this  feature.  Here,  the  opportunity  of  any 
comparisons  between  COMPAS-assisted  and  not  COMPAS-assisted  control  is  much  more 
limited.  In  the  field  test  evaluation,  the  focus  was  much  more  on  verifying  the 
simulation  results  and  generalizing  that  in  terms  of 

-  including  all  working  positions  in  the  control  center  which  are  involved  in  handling 
approaching  aircraft, 

-  handling  all  traffic  situations  that  can  occur  in  real  operation,  and 

-  observations  based  on  long-term  operation  of  the  system. 

The  field  test  evaluation  should  make  use  of  the  three  main  data  sources i  traffic  data, 
controller  activity  and  controller  judgements. 

3.  Technical  implementation  of  COMPAS-OP 

The  following  functions  are  essential  to  the  COM PAS  and  are  processed  with  a  cycle  time 
of  4  seconds  corresponding  to  the  update  rate  of  the  radar  position  data  of  the  aircraft 
responses i 

-  Reception  of  the  radar  data  packets  from  the  BPS  DERD-MC -System,  transformation  into 
an  appropriate  coordinate  system,  identification  of  the  aircraft  data  by  means  of  the 
available  flight  plan  data  base,  handling  of  the  identified  aircraft  parameters, 

-  continuous  speed  calculation  of  the  identified  aircraft  using  the  radar  coordinates, 

-  identification  of  the  route  to  the  gate  by  means  of  the  flight  plan  data  ( XKSD- 
System) ,  calculation  of  the  time  the  aircraft  is  passing  the  metering  fix  and  the 
gate, 

-  calculation  of  the  flight  path  and  the  flight  time  on  the  basis  of  the  aircraft 
performance  data  and  the  parameters  of  the  selected  Standard  Arrival  Route  (STAR) , 

-  computation  of  the  COMPAS  planning  algorithm  giving  the  sequence  of  aircraft,  update 
of  the  suggested  COMPAS  times  over  the  metering  fix  and  gate,  conversion  of  the  time 
updates  into  advisories  to  the  ATC  controllers, 

-  display  of  the  computed  sequence  of  aircraft  and  advisories  on  the  ATC  controller 
working  positions. 

Some  other  functions  are  run  once  or  on  request  only* 

-  Initialization  and  configuration  of  the  COMPAS  system  by  means  of  data  sets 
describing  the  airport  and  airspace  environment  and  the  aircraft  characteristics, 

-  aquisition  of  weather  information  and  flight  plans  which  are  received  about  20 
minutes  before  the  aircraft  enters  the  TMA, 

-  processing  of  the  ATC  controller  keyboard  inputs  as  part  of  the  concept  of  local 
interaction  and  processing  of  resulting  COMPAS  plan  modifications. 

Some  other  functions  are  included  in  the  system,  too,  which  are,  however,  not  part  of 
the  kernel  software.  They  include  data  aquisition,  data  processing  and  quick-look 
functions. 


27-5 


The  sun  of  all  these  functions  fonts  the  basic  part  of  the  operational  COHPAS .  The 
experimental  version  of  COHPAS  included  these  functions,  too,  but  aoae  simplifications 
were  tolerated  because  of  the  United  number  of  working  positions  and  the  application  of 
standard  interface  components.  In  addition  the  greater  number  and  the  local  accomodation 
of  the  displays  and  keyboards,  the  interface  to  the  ATC  computers  employing  appropriate 
protocol  specifications  and  a  reduced  cyle  time  compared  to  the  experimental  system  had 
to  be  taken  into  account  in  converting  the  experimental  into  the  operational  system.  The 
specifications  and  restrictions  presented  led  to  a  complete  reorganisation  of  the  data 
processing  concept.  The  single  computer  solution  was  discarded  and  a  distributed  data 
processing  system  was  selected  in  which  the  functions  interface  to  the  ATC  system, 
protocol  conversion,  pre-processing  of  the  ATC  data,  the  COHPAS  planning  algorithm  and 
the  human  interface  are  run  on  separate  computers  linked  by  a  Local  Area  Network  (IAN) 

( figure  4 ) . 


Figure  4  COHPAS -OP  processing  system 

The  functions  data  aquisition  and  data  pre-processing  are  assembled  into  the  Interface- 
Computer  (SR).  All  the  functions  to  interface  the  system  with  the  ATC  computers  are 
concentrated  here.  The  protocol  handling,  the  pre-processing  of  the  received  ATC  data 
and  some  form  of  data  conversion  are  done  by  this  computer.  For  the  physical  interface 
of  the  radar  data  and  the  processing  on  the  lowest  level  of  the  protocol  specification, 
an  intelligent  interface  was  built  which  is  part  of  the  Interface-Computer  and  which 
reduces  its  processing  load.  Another  interface  is  used  for  the  communication  of  COMPAS 
with  the  central  ATC  flight  plan  information  and  distribution  system  (ZKSD,  DUV)  which 
makes  available  the  flight  plan  and  weather  information. 

The  COHPAS  Main-Computer  (CR)  receives  the  pre-processed  data  from  the  Interface- 
Computer  and  runs  the  COMPAS  planning  algorithm.  The  generated  sequence  of  aircraft  and 
advisory  information  are  then  transmitted  to  the  Displaystation-Computers  to  display  the 
appropriate  sequence  of  aircraft  to  the  ATC  controllers.  Requested  modifications  of  the 
planned  sequence  are  entered  by  the  controller  by  means  of  the  function  keyboard  and  are 
passed  back  to  the  Main-Computer  which  takes  into  account  this  information  in  the  next 
cycle  of  the  COHPAS  planning  algorithm. 
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The  display  and  input  functions  are  assigned  to  Displays tat ion -Computers  (AR)  which  get 
their  information  from  the  COMPAS  Main-Computer.  Each  ATC  controller  position  to  be 
equipped  with  the  COitfAS  system  has  it's  own  computer,  a  display  and  a  function 
keyboard.  The  Displaystation-Computers  are  configured  according  to  the  type  of  ATC 
controller  working  position. 

All  computers  are  linked  to  each  other  by  a  Local  Area  Network  (LAN) .  The  LAN  provides 
the  necessary  comunication  to  distribute  the  information  among  the  computers  and  allows 
a  local  separation  of  the  individual  units. 

The  data  flow  which  results  from  the  hardware  concept  of  the  system  is  shown  in 
figure  2. 

The  advantages  of  the  implemented  system  structure  aret 

-  Improved  processing  power  due  to  the  distribution  of  the  required  functions  on  more 
than  one  computer, 

-  separation  and  modularization  of  groups  of  functions, 

-  more  efficient  integration  and  test  of  subsystems, 

-  local  distribution  and  separation  of  the  ATC  controller  display  stations, 

-  ability  to  expand  the  system  in  particular  to  a  greater  number  of  ATC  controller 
working  positions  if  needed. 

The  display  and  keyboard  subsystem  is  an  important  part  of  COMPAS  because  the  human 
interface  components  are  concentrated  here.  In  the  experimental  COMPAS  the  display  and 
keyboard  layout  was  investigated,  tested  and  optimized.  Only  minor  modifications  had  to 
be  made  for  the  operational  COMPAS.  A  graphic  subsystem  is  used  to  display  the  planned 
sequence  of  aircraft  in  16  colors  with  a  resolution  of  756  x  512  pixels  (figure  5).  For 
the  interaction  with  COMPAS  an  optimized  small  function  keyboard  is  used  (figure  6), 
which  is  linked  to  the  Displaystation-Computer  by  a  serial  data  line.  Some  of  the 
interaction  sequences  are  handled  locally  in  order  to  reduce  the  overhead  demands  on  the 
cossnunication  link  and  the  Main-Computer. 


Figure  5 
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Figure  6  COMPAS  function  keyboard 


The  given  specification  to  handle  70  planned  and  controlled  aircraft  approaching  the 
airport  at  the  same  time  was  verified  in  the  simulation  after  the  integration  and  the 
first  test  of  the  COMPAS  subsystems.  For  this  purpose  the  Air  Traffic  Management  and 
Operations  Simulator  (ATMOS)  of  DLR  was  complemented  by  simulated  DERD-MC  and  ZKSD 
functions  and  interfaces.  The  tests  were  run  satisfactorily  at  peak  traffic  loads  and 
all  COMPAS  system  components  (DERD-MC  Interface,  Interface-Computer  and  Main-Computer) 
had  sufficient  spare  .capacity  even  to  implement  future  expansions  of  COMPAS.  In  the 
tests  special  operational  conditions  were  simulated,  too.  They  included  radar  dropouts, 
aircraft  crossing  radar  receiving  areas,  the  duplication  of  code  allocation  and 
incorrect  inputs  of  callsigns  by  the  ATC  controllers  (e.g.  LH123  rather  than  DLH123). 

The  installation  of  the  system  at  the  ATC  center  of  the  Frankfurt  airport  was  started  in 
the  first  week  of  April  in  1989.  A  detailed  planning  of  all  activities  was  necessary  to 
avoid  disturbances  of  the  ongoing  ATC  operations.  After  the  training  of  all  400 
controllers  and  the  servicing  staff  was  completed  the  displays  and  keybords  were  placed 
at  their  final  positions  within  2  days.  On  18th  of  Semptember  1989  COMPAS  was  put  into 
operation  at  the  Frankfurt  ATC  center.  Figure  7  shows  the  approach  position  with  the 
COMPAS  display  located  on  the  lefthand  side  of  the  radar  display  and  on  top  of  the 
Heather  Information  Display. 


Figure  7  COMPAS  display  in  the  ATC  APPROACH  of  Frankfurt 
4.  Results  of  the  Field  Teat  Evaluation 

For  a  detailed  description,  it  is  helpful  to  distinguish  between  results  which  apply  to 
APPROACH  control,  to  ACC  (Area  Control  Center)  control,  and  to  approach  traffic  as  a 
whole. 

APPROACH  Control 

Seeing  that  COMPAS  makes  an  overall  plan  which  aims  at  an  easy  flow  of  the  approach 
traffic,  thereby  integrating  all  areas  and  functional  control  units  involved,  a  central 
parameter  of  traffic  flow  or  landing  rate,  respectively,  needs  to  be  specified.  COMPAS 
always  plans  for  a  preselected  traffic  flow  rate  which  can  be  varied  manually  by 
APPROACH  control  due  to  numerous  factors  (wheather,  runway  condition,  departures,  etc.). 
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This  is  done  by  using  the  FLOW  input  function  of  the  system  to  select  s  minimal 
separation  in  Nautical  Niles  (NM)  applying  to  aircraft  on  final  approach. 

So  the  selected  FLOW  becomes  a  central  parasieter,  which  has  a  direct  impact  on  ACC 
control,  too,  because  it  determines  immediately  the  maximum  rate  of  aircraft  that  can  be 
handed  over  to  APPROACH  control  at  the  TMA  boundary. 

The  examples  given  in  figure  8  and  figure  9  shall  emphasize  the  importance  of  this 
parameter.  For  two  days  they  show  at  the  left  hand  part  of  the  figures,  over  the  time 
axis, 

-  the  FLOW  as  specified  in  Nautical  Miles  minimum  separation, 

-  the  number  of  aircraft  which,  by  COMPAS  calculation,  theoretically  could  have  passed 
the  Gate  if  there  were  no  other  traffic,  but  actually  have  not  (’holding  aircraft’), 
and 

-  some  traffic  statistics  per  30-min.  interval <  landing  frequency  is  displayed  as  a 
letter  histogram,  with  letters  referring  to  the  classification  of  heavy/medium/light 
aircraft  (obtained  from  actual  time  of  arrival,  ATA) .  The  number  of  intended  landings 
is  displayed  as  a  column  (obtained  from  calculated  time  of  arrival,  CTA) . 

Horizontal  radar  tracks  of  the  two-hours  traffic  peak  from  09.30  to  11.30  are  given  at 
the  right. 


Figure  8  Traffic  flow  example  with  selected  FLOW  of  about  5  NM  (see  text) 
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Both  examples  are  baaed  on  an  identically  high  number  of  approaches  per  day,  vith 
similar  distributions  of  four  characteristic  peaks. 

In  the  day  1  example  (see  figure  8),  with  FLOW  selected  as  5  plus/minus  1  NM  separation 
all  over  the  day,  there  was  always  a  jumpy  increase  of  delays  at  the  peaks,  which  piled 
up  for  hours  until  they  could  be  reduced  at  less  busy  times.  The  horizontal  flight  paths 
of  the  late-morning  peak  showed  an  accumulation  of  holding  patterns. 

In  the  day  2  example  (see  figure  9),  FLOW  was  predominantly  set  to  3  NM  separation.  This 
led  to  a  much  higher  traffic  flow  and  a  clear  traffic  pattern  within  the  TMA.  peaks  were 
worked  off  more  quickly,  and  the  number  of  delays  was  always  kept  low.  In  the  horizontal 
flight  paths  (of  the  same  interval  as  above)  holding  patterns  are  completely  missing. 

It  is  not  a  surprise  that  low  minimum  separation  is  favourable  to  a  high  traffic  flow. 
But,  in  the  case  of  COMP AS ,  where  the  exact  quantitative  variation  of  this  key  parameter 
is  handled  by  controllers  in  a  most  direct  and  simple  way,  it  is  important  that,  via 
FLOW  function,  the  separation  is  always  kept  at  the  lowest  possible  level.  However,  as 
this  is  a  matter  of  many  factors  (e.g.  weather),  a  general  demand  for  lowest  FLOW 
selection,  in  order  to  avoid  delays  or  even  increase  runway  capacity,  is  not  admissible. 

From  this  point  of  view,  the  handling  of  the  FLOW  function  by  the  APPROACH  controllers 
is  interesting,  as  it  developed  through  six  months  of  practice  with  COMP AS .  Figure  10 
shows  the  distribution  of  the  FLOW  applied  during  the  first  two  months  and  the  last 
months  of  the  evaluation  period.  Intervals  of  CAT  II/III  operation  have  been  canceled  in 
both  cases.  There  was  an  obvious  tendency  to  select  more  favourable  low-separation 
values,  at  the  time  of  advanced  experience  with  the  planning  system. 
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Figure  10  Selected  FLOW;  percentage  of  minimum  separation  classes  (in  Nautical  Miles) 
selected  during  the  first  and  the  last  two  months  of  the  evaluation  period. 

As  regards  traffic  flow  in  the  APPROACH  area,  the  early  decisions  on  final  sequencing 
proposed  by  COMPAS  enabled  the  controllers  to  apply,  in  general,  a  more  direct, 
straight-in  guidance,  whereas  before  more  indirect  vectoring  with  flight  path  stretching 
was  quite  usual.  Figure  11  shows  two  typical  examples,  both  referring  to  two-hour  peak 
traffic  periods  which  were  very  similar  from  their  basic  parameters  like  landing  rate 
(ATA  frequency),  mean  arrival  delay,  etc.. 

APPROACH  controllers  judged  the  COMPAS-planned  sequences  as  being  easily  applicable. 
Coordination  with  ACC  control  was  also  judged  as  being  significantly  easier.  Acceptance 
of  the  planning  system  was  generally  high  throughout  APPROACH  control. 
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ACC  Control 


According  to  the  COMPAS  philosophy,  the  individual  aircraft's  tine  budget  should  be 
balanced  before  they  leave  the  Metering  Fix  inbound  (TMA  boundary) ,  in  order  to  fit 
smoothly  into  the  overall-planned  final  approach  sequence.  So,  the  effort  for  doing  this 
is  up  to  the  ACC  controllers.  Although  the  COMPAS  information  over  all  sectors  was 
strongly  appreciated  by  the  ACC  controllers,  putting  the  COMPAS  plans  into  practice  was 
criticised  by  many  of  them  as  bringing  an  increase  of  their  control  load. 

In  total,  acceptance  of  the  system  by  ACC  controllers  was  distinctly  lower  than  by 
APPROACH  controllers. 

This  can  at  least  partly  be  ascribed  to  inconvenient  locations  of  the  COMPAS  displays  at 
some  controller  working  desks,  which  had  to  be  chosen  because  of  technical  reasons. 

However,  as  could  be  observed  from  the  final  application  of  the  questionnaire  to  this 
group,  there  was  a  significant  increase  of  acceptance  regarding  the  COMPAS  planning 
results.  This  was  obviously  due  to  several  program  refinements  which  had  been 
implemented  during  the  evaluation  period  in  order  to  cope  e.g.  with  some  locally 
specific  requirements  within  the  Frankfurt  airspace. 

Looking  at  the  results  of  the  ACC  controller  efforts  to  contribute  their  part  to  the 
overall  plan,  it  has  to  be  stated  that  metering  accuracy  (i.e.  the  average  difference 
between  planned  and  actually  observed  time  overhead  the  Metering  FIX)  stabilized  very 
quickly  at  a  constant  level.  Figure  12  shows  the  metering  accuracies  at  the  two  most 
important  fixes  for  Frankfurt,  as  calculated  for  specified  time  intervals  of  the  test 
period.  It  indicates  that  controllers  succeeded  very  quickly  in  delivering  the  aircraft 
from  their  sectors  always  within  tolerable  time  limits  to  APPROACH  control,  according  to 
the  COMPAS  plan. 
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C0MP4S  Metering  Accuracy  at  Northern  Fix  GED 
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COMPAS  Metering  Accuracy  at  Southern  Fix  PSA 


Figure  12  Metering  accuracies  for  specified  time  intervals  of  the  evaluation  period 

At  the  beginning  of  the  test  period,  this  high  degree  of  conformity  with  the  planned 
traffic  flow  was  achieved  at  the  expense  of  many  manual  inputs  into  the  planning  system. 
Figure  13  shows  the  development  of  keyboard  input  frequencies  over  the  whole  test 
period.  As  can  be  seen,  there  was  a  tendency  to  decrease  towards  the  end,  finally 
leading  to  an  average  of  about  15  keyboard  entries  per  hundred  approaches. 
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COMPAS  Keyboard  Inputs 
Frequency  per  IOO  Aircraft 


COMPAS  Keyboard  Inputs 
Frequency  per  100  Aircraft 


Figure  13  Keyboard  input  frequencies  for  specified  time  intervals  of  the  evaluation 
period 

This  tendency  presumably  reflects  several  factors,  among  which  at  least  the  following 
can  be  named i 

-  proceeding  experience  reduced  initially  prevailing  tendencies  to  try  out  all  system 
functions, 

-  program  refinements  improving  planning  performance  reduced  the  necessity  of  making 
manual  inputs,  as  well  as 

-  an  increasing  tendency  towards  low-separation  FLOW  selection  made  control  of  traffic 

®n<f  actions,  e.g.  to  reduce  an  aircraft,  less  frequent, 

which  then,  taken  altogether,  might  have  been  the  reason  for  the  raising  acceptance  of 
COMPAS  planning  results. 
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Approach  Traffic  aa  a  Whole 

Aa  a  finding  which  hold*  for  the  approach  traffic  as  a  whole,  observations  of  better 
first-come-first-served  compliance  with  the  planning  system  were  further  supported. 
Figure  14  contrasts  pairwise  COMPAS-  with  non  COMPAS -sequences  from  two-hour  traffic 
peaks  which  were  very  similar  in  all  other  respects.  In  general,  rank  displacements  with 
COMPAS  were  smaller  than  before. 
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Figure  14  Rank  displacements  from  first-come-first-served  sequence 

So,  there  is  evidence  that  making  use  of  the  planning  aid,  thereby  keeping  the  FLOW 
always  at  an  appropriately  low  separation,  contributes  to  straight  and  easy  traffic 
pattern  as  well  as  to  the  fairness  of  approach  sequences. 
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5.  Conclua Iona 


For  an  evaluation  and  implementation  of  an  operational  version  of  a  planning  system  in 
ATC  like  the  COMPAS-System  in  terms  of  traffic  flow,  system  handling  and  controller 
acceptance,  a  six-month  field  test  was  carried  out.  The  results  indicated  that  the 
planning  system  enabled  controllers  to  establish  preplanned  optimized  approach  sequences 
and  contributed  to  straight  and  easy  traffic  flows. 

As  air  traffic  controllers  will  continue  to  play  a  significant  role  in  the  main  control 
loop,  the  achievement  of  acceptance  is  a  prime  business  when  to  implement  planning 
functions  as  new  ATC  system  elements . 
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Abstract 

This  paper  describes  the  Integrated  Control  and 
Avionics  for  Air  Superiority  (ICAAS)  piloted 
simulation  evaluations,  along  with  the  system 
development  leading  up  to  the  simulations  and  the 
data  analysis  plan  for  evaluating  simulation 
results.  The  ICAAS  advanced  development  program 
is  sponsored  by  the  United  States  Air  Force  Wright 
laboratory  at  Wright  Patterson  Air  Force  Base, 
Ohio.  A  research  and  development  contract  was 
awarded  to  the  McDonnell  Aircraft  Company,  St. 
Louis,  Missouri,  in  September  1987.  The  program 
objective  is  to  develop,  integrate  and  demonstrate 
critical  technologies  which  will  enable  United 
States  Air  Force  tactical  fighter  "blue"  aircraft 
to  kill  and  survive  when  outnumbered  as  much  as 
four  to  one  by  enemy  "red"  aircraft  during  air 
combat  engagements.  Primary  emphasis  is  placed  on 
beyond  visual  range  (BVR)  combat  with  provisions 
for  effective  transition  to  close-in  combat. 

This  paper  provides  an  overview  of  the  ICAAS 
system  and  its  functions.  The  hardware  elements 
needed  to  implement  the  ICAAS  system  are  described 
and  require  high  throughput  parallel  processing 
Reduced  Instruction  Set  Computer  (RISC)  computers 
and  an  advanced  "glass"  cockpit. 

The  development  of  the  ICAAS  system  is  discussed 
as  it  moved  from  rapid  prototyping  to  unit  testing 
of  attack  management  and  flight  Management 
software  and  finally  into  hardware  software 
Integration  testing  prior  to  manned  simulation. 

The  ICAAS  program  is  structured  to  evaluate  system 
performance  in  a  build  up  manner  from  2  blue  vs  2 
red  scenarios  to  4  blue  vs  16  red  scenarios.  Both 
offensive  counter  air  and  defensive  missions  will 
be  simulated.  The  simulation  configurations  for 
both  the  2v8  simulations  which  are  taking  place  in 
1991-1992  and  the  4vl6  simulations  which  will  take 
place  in  1992-1993  are  presented.  A  matrix  of 
test  blocks  for  the  2v8  simulations  is  Included. 

The  Data  Analysis  plan  for  reducing  piloted 
simulation  results  to  assess  system  performance  is 
described.  The  evaluation  of  the  ICAAS  system 
performance  encompasses  not  only  integrated  system 
performance  but  also  performance  of  individual 
ICAAS  subsystems  as  they  are  reflected  by  measures 
of  situation  awareness,  flight  management 
utilization,  weapon  utilization  and  sensor 
effectiveness.  This  includes  use  of  multiple 
measures  of  performance  as  well  as  univariate  and 
multivariate  analyses  to  assess  ICAAS  system 
performance.  (Specific  simulation  results  are 
classified  and  are  not  included  in  this  paper.) 


System  Introduction 

Specific  functions  of  the  ICAAS  system  include 
attack  management,  tactics,  attack  guidance, 
defensive  assets  manager,  and  aircraft  performance 
monitor  as  illustrated  in  Figure  1.  The  latter 
four  are  collectively  referred  to  as  flight 
management. 


Defensive 

Attack  Attack  Assets  Performance 

Management  Tactics  Guidance  Manager  Monitor 


Figure  1.  ICAAS  System  Functions 


Attack  management  automatically  controls  onboard 
sensors  and  computes  a  correlated  summary  of  track 
files  from  ownship  sensors  as  well  as  information 
received  over  the  data  link  from  other  flight 
members.  The  track  file  summary  is  displayed  to 
the  pilot  to  maximize  his  situation  awareness. 

The  tactics  function  uses  a  rule-based  approach 
which  blends  a  number  of  knowledge-based  values  to 
assist  the  pilot  in  assessing  the  overall 
situation.  Scenario  attributes  are  evaluated  in 
real-time  against  a  tactics  knowledge  base, 
extracted  from  pilots,  to  recommend  the 
most  viable  tactics.  Specific  coordinated 
assignments  are  provided  to  each  flight 
member. 

Attack  guidance  provides  flight  trajectory 
information  for  achieving  missile  launch  solutions 
against  multiple  enemy  aircraft  while  maximizing 
ownship  survival.  Faster  than  real-time  aircraft 
and  missile  flyout  models  are  used  to  perform 
engagement  predictions  and  guide  the  aircraft  to 
recommended  launch  points. 
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The  defensive  assets  manager  is  activated  t>y  the 
sensed  launch  of  a  threat  missile  against  ownship. 
An  extensive  data  base  of  early,  midcourse,  and 
endgame  maneuvers  is  used  to  generate  and  validate 
available  evasive  options  and  to  select  the  most 
promising  for  recommendation  to  the  pilot. 

The  performance  monitor  uses  stored  knowledge  of 
the  aircraft  performance  characteristics  to  aid 
the  pilot  in  achieving  the  best  real-time  dynamic 
aircraft  performance.  The  features  of  these 
specific  1CAAS  system  functions  are  addressed  in 
more  detail  in  Reference  (1). 

System  Implementation 

The  Department  of  Defense  standard  Ada  software 
language  is  being  used  for  1CAAS  implementation. 
Host  of  the  software  code  has  been  developed, 
including  100,000  lines  or  over  850,000  32-bit 
words  of  executable  code  plus  275,000  words  of 
data  base.  Rapid  update  rates  which  are  necessary 
to  support  real-time  mission  performance  led  to  a 
computer  throughput  requirement  of  approximately 
15  million  instructions  per  second.  No  available 
flightworthy  computer  with  this  capability  could 
be  found,  so  a  new  computer  was  developed  based  on 
the  MIPS  Corporation  R-3000  32-bit  reduced 
instruction  set  computer  (RISC)  processor.  This 
is  one  of  two  standard  processors  selected  by  the 
Joint  Integrated  Avionics  working  Group.  Each 
processor  is  conservatively  rated  at  five  million 
instructions  per  second.  Three  processors  are 
included  in  a  single  computer  chassis,  resulting 
in  a  throughput  capacity  of  15  million 
instructions  per  second.  One  chassis  hosts  the 
tactics,  attack  guidance,  defensive  assets 
manager,  and  performance  monitor  functions  and  is 
designated  the  ICAAS  Integration  Computer  (IIC). 
The  second  computer,  the  ICAAS  Support  Computer 
(ISC),  hosts  the  attack  management  and  other  ICAAS 
functions.  These  computers  are  flightworthy  and 
will  be  used  in  simulation  evaluations  as  well  as 
flight  test. 

Pilot/vehicle  interface  (PVI)  is  a  major  ICAAS 
system  integration  issue.  No  matter  how  much 
information  can  be  developed  within  the  system, 
effective  combat  performance  can  be  achieved  only 
if  the  pilot  can  easily  understand  and  apply  the 
information.  Too  much  data  and  information  can 
easily  overwhelm  the  pilot.  Efficient  cockpit 
data  management  techniques  are  needed,  including  a 
proper  balance  between  automation  and  manual  task 
allocation. 

An  advanced  cockpit  instrument  panel,  designated 
Cockpit  2000,  has  been  designed  for  ICAAS  as  shown 
in  Figure  2.  Three  multifunction  color  displays 
are  used  to  present  tactical  situation  data, 
weapon  delivery  information,  threat  warnings, 
recommended  tactics,  and  flight  trajectories.  A 
large  center  display  provides  9-1/2  Inches  by 
9-1/2  inches  of  viewing  area  as  the  primary 
situation  awareness  display.  The  other  two 
displays  are  6  Inches  by  6  inches.  A  helmet 
mounted  display  (HMD)  is  provided  for  sensor 
cueing  and  threat  warning.  The  HMD  will  also  be 
used  to  cue  the  pilot  on  where  to  look  for  targets 
as  he  transitions  from  BVR  to  WVR,  thus  providing 
maximum  visual  acquisition  range. 

Inflight  data  entry  will  be  managed  through  the  Up 
Front  Control  (UFC)  panel  which  is  located  just 
below  the  HUD.  Weapon  selection,  target 
designation,  and  display  management  functions  are 
provided  through  standard  hands-on  throttle  and 
stick  switches,  or  by  switches  located  around  the 


perimeter  of  the  three  multifunction  displays.  An 
additional  method  is  provided  by  a  touch  sensitive 
overlay  for  the  large  central  display. 


Figure  2.  Cockpit  Instrument  Panel 


Pilot  working  group  members  nave  been  involved  in 
a  series  of  static  mockup,  rapid  prototyping,  and 
part  task  simulation  experiments  as  the  specific 
cockpit  layout  and  display  formats  have  evolved. 

It  is  essential  to  achieve  a  pilot-friendly 
Implementation  of  the  ICAAS  technology. 

System  Development 

The  ICAAS  system  design  has  been  developed  in  a 
process  that  began  with  rapid  prototyping  on 
workstations,  continued  with  detail  design  and 
verification  of  the  major  system  elements  of 
attack  management  and  flight  management,  and 
culminated  with  hardware/software  integration  and 
testing  in  MCAIR's  Advanced  Integrated  Control 
( AIC)  laboratory.  This  design  is  being  further 
refined  and  evaluated  in  piloted  simulation  and 
will  be  verified  in  limited  flight  tests. 

At  the  neart  of  ICAAS  development  test  and 
evaluation  is  the  Air  Combat  Engagement  System 
(ACES)  which  has  been  used  at  every  stage  of  the 
development  process  and  is  now  described  in 
detail. 

Air  Combat  Engagement  System  -  ACES  is  a  computer 
based  emulation  of  tactical  air  combat.  The  ACES 
design  and  implementation  in  the  ICAAS  system  is 
based  on  extensive  HCAIR  experience  in  developing 
and  employing  a  testing  and  training  capability 
that  is  embedded  on-board  the  fighter  aircraft. 
This  unique  capability,  referred  to  as  on-board 
simulation  (OBS),  was  first  developed  and 
demonstrated  in  the  Integrated  flight  Fire  Control 
(IFFC)  Program  for  bombing  and  air-to-air  gunnery 
weapon  modes.  IFFC  program  engineers  used  the 
mode  extensively  for  system  checkout,  refinement, 
and  integration  testing  in  the  lab,  in  the  manned 
simulator  and  on  the  aircraft  on  the  ground.  Test 
pilots  flew  the  OBS  mode  to  gather  flight  test 
data  on  the  performance  of  the  IFFC  system.  ACES 
was  developed  by  HCAIR  in  a  series  of  Wright 
Laboratory  sponsored  programs  known  as  Onboard 
Simulation  -  Enhanced  to  handle  WVR  and  8VR 
missile  engagements. 


The  ACES  implementation  approach  for  ICAAS  is 
illustrated  in  figure  3.  When  the  pilot  selects 
ACES,  the  digital  aircraft  capabilities  and  flight 
paths,  and  the  relative  geometry  between  the 
ownsnip  and  digital  aircraft,  are  determined  by 
software  resident  in  a  computer  on  the  host 
aircraft.  The  ACES  software  is  integrated  with 
the  ICAAS  system  such  that  the  cockpit  controls 
and  displays  respond  in  the  same  way  as  they  do  in 
tactical  situations  against  real  targets.  As  a 
result,  the  fighter  aircraft  operations  when  using 
the  ACES  mode  are  similar  in  all  important  aspects 
to  those  used  in  tactical  situations.  Moreover, 
if  the  ACES  mode  is  not  selected,  it  does  not 
alter  the  tactical  operation  of  the  fighter 
aircraft. 

The  current  ACES  capabilities  in  ICAAS  include: 

(I)  eight  digital  aircraft  with  a  further  increase 
to  sixteen  planned  for  the  4vl6  simulations,  (2) 
threat  tactics  consist  of  current  intelligence 
information,  (3)  internetted  cooperative  blue 
aircraft  operation,  (4)  missile  scoring  for  the 
amraam  (aim-120)  and  two  threat  missiles,  the 
AA-IOC  and  AIM-9L  (emulating  a  threat  IR  missile), 
and  (5)  countermeasures  (electronic  and 
mechanical)  effects  on  the  blue  and  red  missiles. 

In  the  ICAAS  program,  ACES  will  enable  the  same 
engagements  to  be  flown  in  the  manned  simulator, 
in  the  software  test  facility,  at  the  aircraft 
during  ground  check  out,  and  in  flight.  ACES 
should  significantly  reduce  the  need  for  special 
ICAAS  ground  support  equipment  to  support  flight 
test  while  providing  a  dynamic  closed  loop  testing 
and  checkout  capability.  Without  the  ACES  mode, 
it  would  be  difficult  for  ground  support  equipment 
to  provide  this  capability. 

Another  very  important  capability  provided  by  ACES 
is  the  relatively  large  number  of  engagements  that 


can  be  flown  in  a  flight  hour  when  compared  to  the 
number  of  engagements  flown  when  using  tactical 
aircraft  for  targets.  These  engagements  will  be 
used  for  checkout,  development,  data  recording  and 
pilot  training  on  the  ICAAS  system  in  flight. 

ACES  has  the  capability  to  be  used  in  the  ICAAS 
flight  test  with  two  blue  aircraft.  Threat  truth 
data  generated  by  ACES  on  the  lead  aircraft  will 
be  sent  over  the  intra-flight  data  link  to  the 
wingman.  Then  the  wingman  will  execute  ACES 
sensor  models  to  accept  threats  that  would  be  seen 
by  his  own  sensors.  The  missile  scoring  algorithm 
in  each  blue  aircraft  will  be  called  to  score 
ownship  launches  and  threat  launches  on  ownship. 

Rapid  Prototyping  -  Rapid  Prototyping  (RP) 
workstations  have  been  in  use  since  early  in  the 
program  and  continue  to  provide  the  MCAIR  ICAAS 
program  with  a  rapid  prototyping  capability  for 
real  time  evaluation  of  the  ICAAS  system.  These 
workstations  have  been  used  by  flight  control, 
fire  control,  and  displays  engineers  to  obtain 
much  better  insight  into  the  dynamic  operation  of 
ICAAS  candidate  designs  than  could  be  obtained 
using  batch  analysis  programs.  This  type  of 
insight  is  not  normally  obtained  in  most  programs 
until  the  manned  simulations  phase,  which  is  very 
late  for  making  system  design  changes. 

The  RP  workstations  were  used  in  the  program  by 
software  engineers  to  get  a  preliminary  indication 
of  the  computer  throughput  and  memory  requirements 
for  ICAAS  software.  As  ICAAS  software  development 
continued,  the  workstations  have  been  used  for 
debug,  checkout,  software  interface  definition, 
and  unit  testing.  The  RP  workstations  have  been 
expanded  to  include  1553  links  to  additional 
processors.  These  1553  links  allow  the  ICAAS 
computers  housing  ICAAS  software  to  be  included 
and  used  for  systems  checkout  prior  to  testing 
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Figure  3.  implementation  Approach  and  Features  of  the 
Air  Combat  Engagement  System  (ACES) 
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with  the  rest  of  the  ICAAS  system  computers  in  the  and  validation  of  the  Flight  Management  System 

integration  laboratory  and  the  manned  simulator.  (Tactics,  Attack  Guidance,  DAM,  apm)  in  the  IIC. 

using  the  configuration  shown,  both  lead  and 

Unit  Testing  -  A  specific  application  for  the  wingman  Flight  Management  System  operation  have 

rapid  prototyping  facility  is  its  use  in  the  been  checked  out. 

integration,  verification  and  validation  of  the 

operational  flight  programs  for  the  ISC  computer.  AIC  Laboratory  Integration  Testing  -  The 
Figure  4  illustrates  the  MCAIR  RP  environment  laboratory  configuration  (Figure  7)  was  developed 

which  has  been  set  up  foe  verification  and  to  study  two  aircraft  IIC/ISC  interface  issues, 

validation  of  the  ACES,  AMIC  and  emulated  ICAAS  This  configuration  uses  the  RP  workstations  to 

Attack  Management  ( I  AM)  code  in  the  ISC.  This  was  simulate  the  Central  Computer  and  data  link.  A 

used  prior  to  the  availability  of  the  actual  I AM  IIC/ISC  pair  of  computers  is  linked  to  each 

code.  workstation. 

The  I AM  associate  contractor,  Northrop,  is  using  The  configuration  shown  in  Figure  8  has  been  used 

the  RP  environment  shown  in  figure  5  for  the  in  the  period  preceding  2vN  Manned  Simulation 

integration,  verification  and  validation  of  the  testing.  It  simulates  a  second  F-15  aircraft 

I  AM  operational  flight  program  in  the  ISC  equipped  with  all  ICAAS  hardware.  A  second  set  of 

computer.  Lead/wingman  aircraft  operation  is  ICAAS  hardware  (CC,  IIC,  ISC)  was  installed  on  a 

being  simulated  to  check  out  the  internetting  second  (F-15)  test  bench.  Information  is  passed 

function  of  the  IAM  software.  by  a  data  link  simulator.  It  provides  an 

independently  controllable  wingman  which  is  using 
MCAIR' s  subcontractor,  Lear  Astronics,  has  also  the  same  OFP  as  the  one  used  in  manned  simulation 

acquired  an  RP  environment  shown  in  Figure  6  which  and  flight  test, 

they  are  using  for  the  integration,  verification 
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Figure  4.  MCAIR  ACES/AMIC/ISC  Rapid  Prototyping  Configuration 
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Northrop  IAM/ISC  Rapid  Prototyping  Configuration 
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Figure  6.  Lear  Astronics  ACFMS/IIC  Rapid  Prototyping  Configuration 
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Figure  7.  Two  Aircraft  IIC/ISC  Test  Configuration 
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Figure  8.  ICAAS/F-15  Hardware/Software 
Test  Facility  Configuration,  2vN 


Simulation  Description 

Hardware  Configuration  -  Figure  9  shows  details  of 
the  ICAAS  manned  simulation  configuration  for  the 
2vN  full  mission  simulations.  N  represents  the 
number  of  threats  and  can  vary  from  2  to  8.  Both 
blue  cockpits  have  Cockpit  2000,  one  implemented 
In  a  Manned  Air  combat  Simulator  dome,  the  other 
In  a  reconflgurable  crewstatlon.  Two  sets  of 
ICAAS  computational  equipment  (CC,  ISC,  IIC)  are 


required.  The  displays  are  simulated  and 
controlled  by  IRIS  and  IMI  computers.  Three  SEL 
host  computers  are  required.  The  Oata  Link  Is 
emulated  througn  the  Data  Distribution  System. 

The  third  and  fourth  blue  aircraft  required  for 
the  4vl6  simulations  will  use  Super  Manned 
Interactive  Crewstations.  Each  will  have  the 
Cockpit  2000  display  on  a  large  Cathode  Ray  Tube 
and  use  out  the  window  and  HUD  displays  projected 
on  a  screen  forward  of  the  crewstatlon. 
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Figure  9.  2VN ICAAS  Simulation  Hardware  Configuration 

Full  Mission  Simulation:  2  Manned  vs  Up  to  3  Manned  +  5  Digital 


Four  sets  of  IIC/ISC  equipment  will  be  required. 
These  will  be  laboratory  nonflightworthy  computers 
different  from  those  used  in  the  earlier  ZvN 
simulations  and  flight  test.  We  plan  to  use  IRIS 
workstations  to  emulate  the  Central  Computer  and 
datalink  as  shown  in  Figure  10.  Five  SEl 
computers  will  be  required  to  host  the  environment 
of  4  blue  aircraft  and  16  red  aircraft. 

Software  Configuration  -  The  ICAAS  simulations 
involve  a  standard  F-15  to  be  used  to  generate 
baseline  results  and  an  ICAAS  equipped  F-lS.  In 
addition  it  will  also  include  an  advanced  aircraft 
with  and  without  the  ICAAS  system. 

For  the  baseline  results,  all  simulation  software 
is  contained  in  the  simulation  SEL  computers  as 
shown  in  Figure  11. 

For  the  ICAAS  equipped  aircraft  simulations,  the 
software  is  distributed  as  shown  in  Figure  1Z. 

All  ICAAS  system  software  is  distributed  among  the 
IIC,  ISC  and  CC.  The  ISC  also  contains  sensor 
models  for  the  radar.  Infrared  Search  and  Track 
Sensor  (IRSTS),  Interrogate  Friend  or  Foe  (IFF), 
Electronic  Warfare  Warning  System  (EWWS)  and 
Missile  warning  Sensor  (MWS).  This  was  done  since 
the  ISC  has  more  throughput  than  the  SEL. 

Scenarios  -  The  ICAAS  system  will  be  evaluated 
against  three  type  of  scenarios: 


where  F  means  fighter,  and  B  means  bomber.  There 
will  be  variations  in  red  aircraft  initial 
positions  for  each  of  these  three  missions. 

Simulation  Test  Matrix  -  The  top-level  simulation 
test  matrix  is  presented  in  Figure  13  and 
discussed  in  Reference  Z.  A  necessity  in  any 
attempt  to  quantify  performance  improvements  is  to 
have  a  well-defined  baseline  for  comparison.  The 
ICAAS  test  matrix  has  two  such  baselines.  Block  1 
is  the  F-15  baseline  with  a  Mechanically  Scanned 
Antenna  (MSA)  radar,  no  Intraflight  data  link,  a 
standard  F-15C  cockpit,  no  Low  Observability  (LO) 
features,  and  no  ICAAS  flight  management  or  attack 
management  capability. 

The  second  baseline  is  defined  in  Block  8.  This 
b.aseline  is  representative  of  the  next  generation 
high  performance  front-line  USAF  fighter  having  an 
Electronically  Scanned  Antenna  (ESA)  radar,  an 
mtraflight  data  link,  three  glass  cockpit 
displays,  LO  signatures,  and  an  attack  management 
system  based  on  the  Air-to-Air  Attack  Management 
program.  Missing  from  Block  8  are  the  ICAAS 
flight  management  functions,  whose  performance 
increments  will  be  obtained  by  comparing  Block  9 
results  with  the  Block  8  baseline.  The 
performance  increments  resulting  from  applying 
full-up  ICAAS  functions  to  a  current  day  fighter 
will  fall  out  of  the  comparison  of  Block  3  to 
81ock  1  results. 


o  AWACS  Defense  Mission  ZvZ(F) 
o  Base  Defense  Mission  Zv4(F)  +  4(B) 
o  Fighter  Escort  Mission  Zv6(F) 
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Figure  11.  Baseline  F-15  Software  Configuration 
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Figure  12.  ICAAS  Simulation  Software  Configuration 
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It  can  be  seen  by  examining  the  Figure  13  test 
matrix  that  other  blocks  were  designed  to  also 
quantify  the  individual  performance  increments 
resulting  from  an  ESA  radar,  an  attack  management 
system,  to  technologies,  and  an  intraflight  data 
link.  Other  blocks  will  investigate  the  effects 
of  weather  (Block  12)  and  of  the  Electronic 
warfare  (Ew)  environment  (Blocks  6  and  13)  on 
ICAAS  system  performance..  Block  7  will  produce 
manned  simulation  results  that  can  be  compared 
directly  to  data  obtained  from  flight  tests. 

Three  separate  and  major  manned  simulation 
sessions  are  planned  at  the  contractor  facilities 
under  the  ICAAS  program.  Each  will  use  the  basic 
test  matrix,  but  system  capabilities  will  be 
varied  to  correspond  to  performance  levels  typical 
of  the  years  1995,  1998,  and  2002.  Countermeasure 
technology  progresses  from  current  day  chaff  and 
flares  to  conceptual  RF  towed  decoys  in  the  last 
simulation  session.  Self  protection  system  ranges 
and  angular  coverages  increase  between  simulation 
entries.  Data  link  ranges  and  sophistication  of 
the  tactics  algorithm  also  progress.  AMRAAM 
improvements  are  postulated  which  would  increase 
its  range  and  radar  sensitivity  in  the  last 
simulation  entry.  Corresponding  performance 
improvements  are  also  granted  to  enemy 
capabilities.  For  instance,  while  the  AA-10C  is 
the  threat  medium  range  missile  in  the  first 
simulation,  the  projected  Soviet  FOMRAAM  (Follow 
On  Medium  Range  Air-to-Air  Missile)  becomes  the 
primary  threat  missile  for  the  last  of  the  three 
simulation  sessions. 

Data  Analysis 

The  ICAAS  evaluation  simulation  will  employ 
subjective  and  objective  measurement  to  assess 
ICAAS  system  success.  These  measurements  are: 
workload,  situation  awareness,  pilot  acceptance, 
and  objective  data.  Video  tape  of  cockpit 


displays  will  also  be  recorded  and  used  to  assess 
the  operation  of  the  ICAAS  system. 

Workload  -  The  Subjective  workload  Assessment 
Technique  (SWAT),  developed  by  the  Air  Force 
Armstrong  Aerospace  Medical  Research  Laboratory 
(AFAAMRl)  will  be  used  for  workload  measurement. 
This  measure  is  relatively  unobtrusive  and 
requires  little  effort  from  the  participant. 

SWAT  treats  workload  as  comprised  of  three 
components.  These  components  are  time  required  by 
the  task,  effort  required  by  the  task  and  the 
stress  imposed  by  the  task.  Participants  rate 
each  component  individually  on  a  scale  from  one  to 
three,  as  shown  in  Figure  14.  These  rankings  are 
analyzed  mathematically  to  produce  a  single  number 
which  rates  total  workload  on  a  scale  from  zero  to 
one  hundred,  zero  being  the  minimum  workload,  one 
hundred  being  the  maximum. 

Situation  Awareness  -  The  situation  awareness 
rating  scale  to  be  used  are  shown  in  Figure  IS. 
Situation  awareness  items  will  be  combined  with 
workload  and  pilot  acceptance  items  and 
administered  in  written  form  to  each  pilot  after 
each  run. 

Pilot  Acceptance  -  The  ICAAS  system  offers 
innovative  solutions  to  pilot  situation  awareness 
and  situation  assessment  problems.  Regardless  of 
the  intelligence  built  into  these  systems,  they 
cannot  assist  pilots  unless  pilots  accept  them  and 
can  use  them  as  useful  aids  in  the  conduct  of 
their  mission.  Questionnaires  administered  after 
each  run,  at  the  completion  of  each  test  block, 
and  at  the  end  of  the  test  period  will  assess 
pilot  opinion  on  the  concepts  and  implementation 
of  the  ICAAS  systems  including  the  Tactics 
Algorithm,  Attack  Guidance,  data  link,  1AM 
and  the  Cockpit  2000. 
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Figure  13.  Mission  Simulation  Test  Matrix 
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I.  Tim*  Load 

1 .  Often  Have  Spare  Time.  Interruptions  or  Overlap 
Among  Activities  Occur  Infrequently  or  Not  at  Alt. 

2.  Occasionally  Have  Spare  Time.  Interruptions  or 
Overlap  Among  Activities  Occur  Frequently. 

3.  Almost  Never  Have  Spare  Time.  Interruptions  or 
Overlap  Among  Activities  Are  Very  Frequent  or 
Occur  All  the  Time. 

II.  Mental  Effort  Load 

1 .  Very  Little  Conscious  Mental  Effort  or  Concentration 
Required.  Activity  Is  Almost  Automatic.  Requiring 
Little  or  No  Attention. 

2.  Moderate  Conscious  Mental  Effort  or  Concentration 
Required.  Complexity  of  Activity  Is  Moderately  High 
Due  to  Uncertainty,  Unpredictability,  or  Unfamiliarity. 
Considerable  Attention  Is  Required. 

3.  Extensive  Mental  Effort  and  Concentration  Are 
Necessary.  Very  Complex  Activity  Requiring  Total 
Attention. 

III.  Psychological  Stress  Load 

1 .  Little  Confusion,  Risk,  Frustration,  or  Anxiety  and 
Can  Easily  Be  Accommodated. 

2.  Moderate  Stress  Due  to  Confusion,  Frustration,  or 
Anxiety.  Noticeably  Adds  to  Workload.  Significant 
Compensation  Is  Required  to  Maintain  Adequate 
Performance. 

3.  High  to  Very  Intense  Stress  Due  to  Confusion. 
Frustration,  or  Anxiety.  High  to  Extreme 
Determination  and  Self-Control  Required. 

GP14-0156-014-D/kch 

Figure  14.  SWAT  Rating  Scales 
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Figure  15.  Situation  Awareness  Rating  Scale 
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Objective  Data  -  fin  end-of-run  summary  (Figure  16) 
and  event  ledger  will  be  the  data  used  to  compute 
the  objective  Measures  of  Performance  (MOPs)  shown 
in  figure  17. 


The  event  ledger  will  be  used  to  record 
"snapshots"  of  significant  data  at  critical  points 
such  as  tactic  selection  or  weapon  employment. 

The  end-of-run  summary  will  record  data 
accumulated  during  the  run. 


ICAAS  Evaluation  Simulation  (IE8-1B) 


Data:  OOMMMVY 

Tima:  HHrMM  Run  Number*  Scenario 

A/C  Loaa  Data 

•  RadKMt 

-  Number  of  Blue  A 1C  Killed  by  MICS 

-  Number  of  Blue  A/C  Killed  by  Digitals 

-  Number  of  Blue  A/C  Killed  by  Blue* 

•Blue  Kills 

-  Number  of  MICS  KWed  by  Blue  A/C 

-  Number  of  Digital  Fighters  Killed  by  Blue  A/C 

-  Number  of  Bombers  Kited  by  Blue  A/C 

-  Number  of  Rad  A/C  Killed  by  Reds 

■  Losses 

-  Number  of  Blues  Hitting  Ground 

-  Number  of  Blues  Out  at  Fuel 

-  Number  of  Reds  Hitting  Ground 

-  Number  of  Reds  Out  ot  Fuel 

•  Mission  Success  Data 

-  Number  of  Penetrating  Threats 

-  Number  of  Red  Bombers  on  Target  (ABD) 

-  Number  of  Blue  Bombers  on  Target  (Escort) 

-  Number  of  Red  Missiles  Targeted  on  AWACS 

-  Number  of  AWACS  Killed 

-  Number  of  Missiles  Launched  at  AWACS 

-  Average  of  Missiles  Launched  at  AWACS 

•  Targeting  Data 

-  Number  of  Rads  Tracked  by  Blues 

-  Number  of  Reds  Assigned  by  Blues 

-  Number  of  Reds  Launched  on  by  Blues 

-  Number  of  Reds  Launching  Missiles 

-  Number  of  Blues  Tracked  by  Rads 

-  Number  of  Blues  Assigned  by  Reds 
-Number  of  Blues  Launched  on  by  Reds 

-  Number  of  Blues  Launching  Missiles 

•AIM-120  Data -(Blue  Only)  --B1--  --B2-- 

-  Number  Launched 

-  Number  Achieving  Kill 

-  Average  Launch  Range  -  Percent  FL*, 

-  Number  Unguided  Before  Autonomous 

•  AIM-9  Data  •  (Blue  Only) 

-  Number  Launched 

-  Number  Achieving  Kill 

-  Average  Launch  Range  -  Percent  F^, 

•  Fuel 

-Fuel  at  Start 

-  Fuel  at  End  of  Run 

•  Total  Time  Within  Ml Z 

•  Total  Time  Within  Data  Link 

•  Total  Mission  Time 

•  Disengage  Cue  Following 

•  Total  Time  In  ICAAS  Modes 
-TacUca 

-  Attack  Guidelines 
-DAM 

-GCAS 

-  MCAS 
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Figure  16.  End  of  Run  Summary  Data 


Mteefen  Success 

•  Number  of  Penetrating  Threats 

•  Number  of  Red  Bombers  on  Target 

•  Number  of  Bfue  Bombete  on  Target 

•  Percent  of  AWACS  Survkral 

•  Average  PR  of  MIssHee  Launched  at  AWACS 

Engagement  Success 

•  Exchange  Ratio 

•  Loaa  Rate  Advantage 

•  Percent  Red  Aircraft  at  Which  Blue  Fired  (By  Claaa) 

•  Percent  Surviving  Aircraft  That  Did  Not  Fire  a 
Weapon  (Blue  and  Rad) 

•  Blue  Kitla 

•  Blue  Losses 

•  Blue  Valid  Launches 

•  Red  Valid  Launches 

Situation  Awareness 

•  Number  of  Tracks  Initialed  by  Blue 

•  Percent  of  Red  Forces  Tracked 

•  Range,  Time  of  First  Red  Track  File  Generated 

•  Range,  Time  at  First  Blue  Track  File  Generated 

•  Number  of  Hostile  IDs  Before  Preferred  Launch  Range 

•  Number  of  Friendlies  or  Neutrals  Targeted  When 
Tactic  Accepted 

•  10  Contributors 

•  Percent  of  MRMs  Double  Targeted 

•  Percent  of  SR  Ms  Double  Targeted 

•  Percent  of  Opposing  Aircraft  Targeted 

•  Number  of  Times  Each  Blue  Aircraft  Launches 
Weapon 

•  Frequency  of  AIM- 120  Becoming  Unguided  in  Flight 

•  Total  Time  Within  MIZ 

•  Average  AIM-120  Launch  Range 

•  Average  Percentage  of  Time  Blue  Aircraft  Are 
Intemetted 

•  Number  of  Launches  (SRM,  MRM) 


Decisions 

•  Weapon  Launch  Range  by  Type  Relative  to  R  max  .  R  ne 

•  F-Potes 

•  Number  of  Blue  Weapons  launched  Before  First  Red 
Launch 

•  Disengage  Cue  Following 

•  Disengage  Range  From  Targets'  Centroid 

•  Reattack  Range  From  Targets'  Centroid 

•  Tims  end  Range  When  Blue  Aircraft  Committed 
•Fuel  Usage 

•  Percent  of  Assigned  Targets  at  Which  Blue  Launched 

•  Duration  of  Coupled  Flight  by  Mode 

-  Number  of  Blue  Launches  Wihout  Shoot  Cue 

•  Number  of  Blue  Successful  Launches 

•  Valid  Red  Launches  by  Quadrant 

•  Blue  Launch  Range  by  Quadrant 

•  Average  End  Game  Velocities  of  Missiles  Launched 
at  Blue 

•  Number  of  Blue  Missiles  Launched  From  Each 
Quadrant 

•  Number  of  Valid  Blue  Missile  Launches  in  Each 
Quadrant 

Degrees  of  Covertness 

•  Number  of  Detects  and  Tracks  by  Adversaries 

•  Percent  of  Blue  Forces  Detected,  Targeted 

Other 

•  Success  of  Ground  Collision  Monitoring  -  Minimum 
Atltudo 

•  Success  of  Mld-AIr  Collision  Monitoring  -  Minimum 
Distance  Between  Aircraft 

Subjective  Data 
•Workload 

•  Situation  Awareness 

•  Verbal  Communication 
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Figure  17.  Measures  of  Performance 
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Primary  Analysis  -  The  data  from  the  ICAAS  manned 
simulations  will  be  analyzed  in  two  stages.  The 
first  set  of  analyses  will  focus  on  ICAAS  tactical 
effectiveness  using  objective  HOPS  in  the  mission 
effectiveness  and  engagement  success  categories 
and  the  subjective  measure  of  workload. 

The  multivariate  analysis  will  be  a  two-way 
hierarchical  analysis  of  variance  (HANOVA)  using 
Number  of  Penetrating  Threats,  Loss  Rate 
Advantage,  and  Slue  workload  as  dependent 
variables.  The  two  independent  variables  will  be 
Test  81ock,  which  generally  relates  to  blue 
aircraft  capabilities,  and  Scenario,  which  relates 
to  the  number  and  type  of  the  threat.  The 
multivariate  tests  will  quantify  ICAAS 
system  tactical  effectiveness  as  it  relates 
to  the  objectives  cited  in  the  Simulation 
Test  Matrix  (Figure  13). 

The  univariate  analysis  of  tactical  effectiveness 
will  be  based  on  the  measure  of  effectiveness 
(HOE)  shown  in  Figure  18.  The  HOE  focuses  on 
effectiveness  issues  by  combining  kills  and  losses 
data  with  mission  success  data  using  the  weights 
shewn.  It  will  be  employed  as  a  complementary 
approach  to  the  analysis  of  ICAAS  tactical 
effectiveness.  The  HOE  results  will  be  analyzed 
using  the  same  "completely  within-sub jects"  model 
and  post  hoc  tests  used  for  the  HANOVA  described 
above. 


Mission 

MOE 

AWACS 

Defense 

-0.6  (LRA/TRA)  -0.4  (KBF/TBF) 

Bomber 

Escort 

0.1  (KRF/TRF)  -{0.2  (KBF/TBF)  -0.7  (L8A/TBA)] 

Base 

Defense 

[0.1  (KRF/TRF)  -0.7  (LRA/TRA)]  -0.2  (KBF/TBF) 

LRA  -  Leaked  Red  Attackers. 

Equal  to  number  of  penetrating  threats  in  MOP  list, 
base  defense  only. 

TRA  «  Two  in  AWACS  defense.  Four  in  air  base  defense. 
KBF  =  Blue  losses  in  MOP  list 
TBF  =  Number  of  manned  blue  fighters.  Two  in  IES-1B. 
KRF  =  Blue  kills  in  MOP  list 
TRF  =  Number  of  red  fighters 
LBA  -  Leaked  blue  attackers.  Equal  to  number  of  blue 
bombers  on  target  in  MOP  list. 

TBA  -  Total  blue  aircraft 
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Figure  18.  Measure  of  Effectiveness 

Subsidiary  Analyses  -  These  will  focus  on  issues 
of  special  interest  In  the  evaluation  of  ICAAS 
systems.  These  include: 

o  Situation  Awareness 

o  Flight  Management  utilization 

o  weapon  utilization 

o  Sensor  Effectiveness 

A  multivariate  analysis  will  be  performed  using 
the  hierarchical  model  and  a  small  number  of 
dependent  measures.  The  dependent  measures  will 
be  chosen  from  those  objective  MOPs  relating  to 
Situation  Awareness  and  the  subjective  ratings  of 
Situation  Awareness.  Dependent  measures  will  be 
chosen  for  their  low  correlation  with  other  HOPS 
and  their  validity  as  measures  of  situation 
awareness . 


we  will  separately  assess  the  extent  of  ICAAS 
flight  management  system  usage  with  the  following 
specific  hops. 

o  Duration  of  ICAAS  Modes 

o  Average  End  Game  velocities  of 

Missiles  Launched  at  Blue 
o  Success  of  Ground  Collision  Monitoring 
-  Minimum  Altitude 
o  Success  of  Mid-Air  Collision 

Monitoring  -  Minimum  Distance  Between 
Aircraft 

o  Disengage  Maneuver 

In  each  case  the  average  values  and  the  number  of 
events  on  which  the  average  is  based  will  be 
presented. 

Weapon  use  in  the  test  blocks  will  be  compared 
using  the  "completely  within-subjects" 
hierarchical  HANOVA  model.  The  dependent  measures 
will  be  MOPs  chosen  from  the  following  list  that 
have  low  correlations  with  other  MOPs  on  the  list 
and  have  validity  as  measures  of  weapon  use. 

o  Blue  valid  launches 

o  Percent  of  MRMs  Double  Targeted 

o  Percent  of  SRNs  Double  Targeted 

o  Percent  of  Opposing  Aircraft  Targeted 

o  Frequency  of  AIM-120  Becoming  unguided 
in  Flight 

o  Average  AIM-120  Launch  Range 

o  Number  of  Launches  (SRM,  MRM) 
o  Number  of  Blue  Weapons  Launched  Before 
First  Red  Launch 

o  Number  of  Blue  Successful  Launches 

o  Number  of  Blue  Missiles  Launched  From 
Each  Quadrant 

o  Number  of  valid  Blue  Missile  Launches 
in  Each  Quadrant 

Sensor  effectiveness  in  the  test  blocks  will  be 
compared  using  the  completely  within-subjects 
hierarchical  manova  model.  The  dependent  measures 
will  be  objective  MOPs  chosen  from  the  following 
list  for  low  correlation  with  other  MOPs  on  the 
list  and  validity  as  measures  of  sensor  use  and 
effectiveness. 

o  Number  of  Tracks  Initiated  by  Blue 
o  Percent  of  Red  Forces  Tracked 
o  Range,  Time  of  First  Blue  Track  File 
Generated 

Summary 

The  ICAAS  program  has  been  developing 
innovative  design  concepts  to  assist  tactical 
fighter  pilots  in  defeating  larger  forces  of  enemy 
aircraft.  Avionics,  guidance,  and  control 
functions  are  being  improved  and  extensively 
integrated  to  enhance  pilot  awareness  of  the 
combat  situation,  provide  decision  aiding  in 
evaluating  offensive/defensive  options,  support 
the  pilot  with  precise  execution  of  his  engagement 
decisions,  and  coordinate  the  actions  of 
individual  flight  members  into  an  effective  battle 
team.  Efficient  information  management  made 
possible  by  high  throughput  RISC  based  computers, 
combined  with  advanced  cockpit  display  concepts, 
allow  ICAAS  to  effectively  support  the  pilot  in 
achieving  mission  objectives. 

The  integration  of  the  ICAAS  system  components  was 
a  very  challenging  task.  The  system  development 
and  integration  was  aided  significantly  by  the  use 
of  the  Air  Combat  Engagement  System  (ACES)  and  the 
use  of  Rapid  Prototyping  (RP)  workstations. 
Extensive  use  of  the  MCAIR  Advanced  Integrated 
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Controls  laboratory  was  made  in  preparing  the 
ICAAS  hardware/software  for  simulation  evaluation 
and  flight  test  verification. 

A  unique  feature  of  the  ICAAS  manned  simulations 
was  tne  use  of  flightworthy  computers  as  an 
integral  part  of  the  manned  simulations  right  from 
the  beginning.  This  was  a  necessity  since  these 
flightworthy  computers  were  the  only  ones  with 
sufficient  throughput  to  execute  the  ICAAS  code. 
This  type  of  simulation  configuration  is  more 
difficult  to  initially  setup  and  check  out.  It 
requires  iterative  problem  solving  between  the 
simulation  facility  and  the  integration 
laboratory.  However,  once  checked  out,  it 
provides  a  significant  advantage  in  that 
the  software  is  now  integrated  into  the 
computers  required  for  flight  test. 

All  ICAAS  computer  (IIC/ISC)  software  was 
programmed  in  Ada.  There  are  over  850,000  32-bit 
words  of  executable  code.  We  believe  that  the  use 
of  a  higher  order  language  such  as  Ada  is  the  only 
practical  way  to  develop  so  much  software  in  a 
reasonable  amount  of  time.  It  allows  the  system 
designers  to  develop  the  algorithm  in  the  same 
language  which  is  then  subsequently  tested  in  the 
laboratory,  the  simulator  and  in  flight  test.  It 
would  be  prohibitively  expensive  to  program  ICAAS 
system  computers  in  assembly  language  for 
simulation  and  flight  test. 


The  piloted  simulation  evaluation  is  occurring  in 
three  major  sessions.  The  first  two  consists  of 
two  blue  aircraft  versus  up  to  eight  threat 
aircraft,  involve  two  simulation  cockpits  and  are 
occurring  in  1991-1992.  The  third  session 
consists  of  four  blue  aircraft  against  up  to  16 
threat  aircraft,  involves  four  simulation  cockpits 
and  is  scheduled  to  occur  in  1992-1993.  The 
measures  of  performance  data  generated  in  the 
simulations  will  be  analyzed  to  assess  ICAAS 
system  tactical  effectiveness  along  with  ICAAS 
subsystem  performance  as  it  relates  to  situation 
awareness,  flight  management  utilization,  weapon 
utilization  and  sensor  effectiveness. 
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1  SUMMARY 

This  paper  describes  the  capabilities  and  evolution  of 
a  flight-test  engineer's  workstation  (called  TESTJT-AN) 
from  an  automated  flight-test  management  system.  The 
concept  and  capabilities  of  the  automated  flight-test  man¬ 
agement  system  are  explored  and  discussed  to  illustrate 
the  value  of  advanced  system  prototyping  and  evolution¬ 
ary  software  development. 

2  NOMENCLATURE 

ART  automated  reasoning  tool 

ATMS  automated  flight-test  management  system 

dof  degree  of  freedom 

FTE  flight-test  engineer 

FTTC  flight-test  trajectory  controller 

FTTG  flight-test  trajectory  guidance 

GUI  graphical  user  interface 

HARV  High  Alpha  Research  Vehicle 

RDBMS  relational  database  management  system 

TACT  tactical  aircraft  technology 

3  INTRODUCTION 

This  paper  describes  the  development  and  capabilities  of  a 
flight-test  engineer's  workstation  called  TESTJ’LAN  and 
its  evolution  from  the  automated  flight-test  management 
system  (ATMS).  The  ATMS  was  a  tool  for  flight-test 
planning  and  scheduling;  it  contained  expen  systems  for 
maneuver  ordering,  range  management,  and  maneuver  re¬ 
quirements  evaluation.  These  expen  systems  were  com¬ 
bined  with  three  and  six-degree-of-freedom  simulations, 
state-of-the-an  trajectory  optimization,  and  a  powerful 
graphic  user  interface  to  provide  a  desk  top  workstation. 

‘PRC  Inc.,  Edward*,  California 
“OAC  System*  lac.,  San  Juan  Capistrano,  California 


TEST -PLAN  is  a  computer  program  designed  to  run  on 
standard  graphics  workstations  as  an  aid  to  flight-test  en¬ 
gineers  (FTEs)  in  planning  and  executing  flight-test  pro¬ 
grams.  TEST-PLAN  allows  the  FTE  to  organize  and  file 
extensive  amounts  of  planning  data  while  satisfying  plan¬ 
ning  requirements  on  a  flight-by-flight  basis  using  air¬ 
craft  and  flight-specific  information  about  instrumentation, 
telemetry,  range,  center-of-gravity,  airborne  and  ground 
support,  aerodynamic  configuration,  system  configuration, 
and  payload. 

TEST-PLAN  is  the  result  of  several  generations  of  evo¬ 
lution.  Originally  combined  with  a  maneuver  autopilot, 
the  first  version  of  the  ATMS  was  designed  for  flight- 
test  maneuver  planning  and  scheduling  as  well  as  ma¬ 
neuver  execution  and  real-time  flight-test  monitoring;  this 
first  version  of  the  ATMS  was  demonstrated  in  October 
1987  using  the  NASA  simulation  facility  at  the  Dryden 
Flight  Research  Facility.  A  second  workstation  version  of 
ATMS  evolved  from  lessons  learned  from  the  preliminary 
version — this  second  version  eliminated  the  maneuver  au¬ 
topilot  concept  but  retained  a  real-time  flight  monitoring 
capability;  version  two  of  the  ATMS  was  demonstrated  in 
mid-1990  at  NASA  using  the  F-18  High  Alpha  Research 
Vehicle  (HARV)  flight-test  plans.  A  third  commercial  ver¬ 
sion  of  ATMS  (called  TEST  -PLAN)  resulted  from  the  ear¬ 
lier  experience  and  is  designed  as  a  FTE  aid  in  planning 
and  executing  flight-test  programs;  TEST-PLAN  is  cur¬ 
rently  being  used  or  considered  for  use  by  United  States 
and  international  flight-test  organizations. 

4  THE  AUTOMATED  FLIGHT-TEST  MANAGE¬ 
MENT  SYSTEM 

The  ATMS  was  originally  developed  at  the  NASA  Dry¬ 
den  Flight  Research  Facility  as  a  part  of  the  NASA  Air¬ 
craft  Automation  Program-a  program  focused  on  apply¬ 
ing  interdisciplinary  state-of-the-art  technology  in  artificial 
intelligence,  control  theory,  and  systems  methodology  to 
problems  of  operating  and  flight  testing  high-performance 
aircraft.  In  this  section  we  present  the  background  and  a 
description  of  the  ATMS  [1,2,3]. 
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4.1  Background  of  the  Automated  Flight-Test 
Management  System 

The  ATMS  was  an  outgrowth  of  the  flight-test  trajectory 
guidance  (FTTG)  work  performed  over  the  past  decade  on 
such  programs  as  the  F-1U  Tactical  Aircraft  Technology 
(TACT)  Program,  the  F-15  Propulsion/ Airframe  Integra¬ 
tion  Program,  and  the  F-15  10°-Cone  Program  (4],  The 
FTTG  provided  display  information  to  the  pilot  to  allow 
complex,  demanding  flight  research  maneuvers  to  be  flown 
more  accurately.  The  FTTG  was  extended  to  a  closed- 
loop  system  for  the  Highly  Maneuverable  Aircraft  Tech¬ 
nology  (HiMAT/  Program  flight-test  maneuver  autopilot 
(FTMAP)  [5].  In  conjunction  with  this  flight  research  at 
Dryden,  Integrated  Systems,  Inc.,  under  contract  to  NASA 
has  developed  a  design  methodology  for  these  types  of 
controllers  [6,7,8]  which  has  resulted  in  the  basis  of  a 
flight-test  trajectory  controller  (FTTC)  which  was  flight 
tested  in  early  1990  on  the  F-15  Highly  Integrated  Digital 
Electronic  Control  (HIDEC)  aircraft  [9].  This  FTTC  was 
a  major  component  of  the  ATMS  as  originally  conceived 
and  implemented. 

The  ATMS  project  was  structured  around  a  flight-test 
scenario  and  was  an  extension  of  work  performed  by 
SPARTA,  Inc.,  (SPARTA,  Inc.,  Laguna  Hills,  CA)  un¬ 
der  contract  to  NASA  defining  the  need  for  a  Na¬ 
tional  Remote  Computational  Flight  Research  Facility 
(NRCFRF).  The  work  on  the  NRCFRF  contract  defined 
the  need  for  an  expanded  remotely  augmented  vehi¬ 
cle  (RAV)  capability  and  a  flight  program  to  demon¬ 
strate  that  capability.  In  the  ATMS,  a  range,  en¬ 
ergy,  and  flight-test  monitor  expert  system  was  used 
in  conjunction  with  the  FTTC  to  order  maneuvers 
by  priorities  and  energy  management  considerations 


while  restricting  the  vehicle  to  the  confines  of  a  specified 
Edwards  AFB  test  range.  This  expert  system  could  be  used 
online  to  control  the  research  aircraft  in  flight  and  monitor 
the  progress  of  a  flight  test;  or  offline  as  a  planning  tool  for 
ordering  the  test  maneuvers  for  a  flight  The  expert  system 
used  predictions  of  maneuvers  based  on  simulation  models 
for  planning  and  actual  flight-test  data  measurements  for 
real-time  vehicle  control,  data  monitoring  and  flight  test 
management 

42  Components  of  the  Automated  Flight-Test 
Management  System 

The  main  components  of  the  ATMS  were  a  trajectory  con¬ 
troller  based  oa  the  FTTC  system  [7,8],  a  flight-test  plan¬ 
ning  expert  system,  a  man-machine  interface,  and  a  flight- 
test  monitoring  expert  system.  The  partitioning  of  func¬ 
tions  in  the  ATMS  was  designed  with  two  goals  in  mind; 
minimizing  the  bandwidth  of  the  communication  between 
components,  and  appropriate  distribution  of  functions  be¬ 
tween  numeric  and  symbolic  processing. 

The  components  described  in  this  section  perform  the  flight 
planning  and  monitoring  functions.  The  fully  developed 
ATMS  (Fig.  1)  was  expected  to  perform  program  plan¬ 
ning,  block  planning,  and  in-flight  replanning  which  are 
not  described  herein  as  they  were  never  implemented  in 
the  first  ATMS. 

4.2.1  Trajectory  Controller 

The  trajectory  controller  was  a  collection  of  outer-loop 
guidance  control  laws  which  provide  precise  control  for  a 


Fig.  I  ATMS  functions. 


SIMM 


29-3 


vehicle  performing  high-quality  flight  research  maneuvers 
such  as  level  accelerations,  wind-up  turns,  and  pushover- 
pullup  maneuvers.  The  trajectory  controller  was  algorith¬ 
mic,  implemented  in  FORTRAN  77,  and  executed  on  a 
numeric  processor. 

The  interface  between  the  trajectory  controller  and  the  re¬ 
maining  components  of  the  ATMS  was  designed  to  min¬ 
imize  the  bandwidth  of  the  communications  across  that 
interface.  The  trajectory  controller  accepted  input  com¬ 
mands  consisting  of  an  ordered  list  of  maneuvers  by  type. 
Each  maneuver  consisted  of  a  trim  point,  maneuver  con¬ 
ditions.  and  end  conditions.  These  commands  contained 
from  three  to  seven  parameters  each. 

Once  maneuver  commands  were  received  by  the  trajec¬ 
tory  controller,  the  controller  operated  independently  of  the 
ATMS  until  another  command  list  was  received.  The  tra¬ 
jectory  controller  generated  trajectories  and  trajectory  fol¬ 
lowing  controls  based  on  the  maneuver  commands  and  the 
aircraft  instrumentation. 

4.2.2  Flight-Test  Planning  Expert  System 

Flight-test  planning  must  be  done  at  several  levels.  At  the 
highest  level,  the  flights  required  for  an  entire  program  are 
established  by  the  project  requirements.  At  the  next  level, 
blocks  of  flights  are  determined  by  a  more  detailed  analy¬ 
sis  of  the  project  requirements  and  are  partitioned  accord¬ 
ing  to  similarity  of  prerequisites,  flight  envelope  require¬ 
ments,  and  test  needs  to  establish  an  orderly  progression  of 
blocks  of  flights  satisfying  the  high-level  project  require¬ 
ments.  Within  each  block  a  number  of  individual  flights  are 
identified  based  on  the  detailed  analysis  of  maneuvers  re¬ 
quired  to  satisfy  the  block  requirements.  Individual  flights 
are  then  identified  with  a  number  of  these  maneuvers  and 
the  FTE  must  order  maneuvers  within  a  flight  based  on 
considerations  of  range,  fuel,  and  energy  management,  as 
well  as  maneuver  priorities. 

The  ATMS  implemented  only  the  test  planner  expert  sys¬ 
tem.  The  test  planner  accepted  a  list  of  maneuvers  and  or¬ 
dered  them  using  rules  that  considered  maneuver  priorities, 
energy  management,  test  range  boundaries,  and  envelope 
limitations.  Maneuvers  which  could  not  be  included  in  the 
flight  plan  were  eliminated  from  the  plan  being  developed. 

The  flight-test  planning  expert  system  accepted  test  plan 
inputs  from  the  FTE  using  a  menu  driven  and  icon  based 
man-machine  interface  or  previously  stored  test  plan  en¬ 
tries.  When  the  list  of  test  maneuvers  was  entered  into 
the  ATMS,  the  FTE  selected  the  flight-test  planning  expert 
system  which  then  used  its  knowledge  base  to  order  ma¬ 
neuvers,  prioritize  maneuvers,  and  construct  a  trajectory. 
As  each  maneuver  was  added  to  the  planned  trajectory,  it 
was  tested  to  insure  that  no  system  constraints  had  been 
violated.  When  constraint  violations  occurred,  the  flight- 
test  planning  expert  system  displayed  information  to  the 
FTE  describing  the  constraint  violations  and  provided  an 
explanation  of  the  constraint,  if  requested.  Maneuver  pri¬ 
ority  was  extremely  important  when  fuel  constraints  were 


tested;  lower  priority  maneuvers  were  removed  from  the 
test  plan  to  satisfy  fuel  constraints. 

The  flight-test  planning  expert  system  was  developed  using 
the  Automated  Reasoning  Tool  (ART)  expert  system  de¬ 
velopment  environment  hosted  on  a  symbolic  computer 
with  a  numeric  processor  board.  It  contained  over 
200  rules. 

4.2  .3  Man-Machine  Interface 

The  man-machine  interface  component  of  the  ATMS  pro¬ 
vided  a  means  of  information  entry  and  display.  This  in¬ 
terface  was  used  during  flight  planning  and  flight  plan  exe¬ 
cution.  The  main  display  had  three  major  components:  the 
map.  timeline,  and  command  menu.  In  the  map  section  of 
the  main  display  were  two  types  of  displays:  the  trajectory 
planning  display  (Fig.  2),  and  the  trajectory  map  display 
(Fig.  3).  These  map  displays  presented  a  two-dimensional 
view  of  the  test  range  with  the  aircraft  trajectory  superim¬ 
posed.  The  stored  map  was  larger  than  the  portion  pre¬ 
sented  on  the  display.  Pan  and  scroll  were  accomplished 
by  using  the  mouse  to  choose  an  appropriate  button  de¬ 
picted  across  the  top  of  the  display.  A“navigate"  button 
was  also  i  ncluded  to  quickly  determine  course  and  distance 
between  present  aircraft  position  and  any  point  within  the 
stored  map.  The  timeline  component  of  the  main  display 
presented  information  on  the  aircraft  trajectory  in  terms  of 
altitude  as  a  function  of  time  or  events.  Figure  4  shows  a 
timeline  display  of  altitude  as  a  function  of  time.  Timeline 
scroll  buttons  allowed  the  FTE  to  examine  different  time  or 
event  segments  by  scrolling  the  timeline.  The  command 
menu  portion  of  the  main  display  allowed  the  user  to  se¬ 
lect  (using  “mouse”  or  keyboard  inputs)  ATMS  operational 
modes,  maneuvers,  or  explanations  of  ATMS  actions. 

The  man-machine  interface  was  rule  based  with  over 
200  rules  and  presented  on  the  computer  monitor  and  key¬ 
board.  The  interface  was  developed  in  ART. 

42.4  Flight-Test  Monitor  Expert  System 

The  flight-test  monitor  expert  system  provided  an  inter¬ 
face  between  the  FTE  and  either  the  planned  trajectory 
or  the  actual  trajectory  (whether  generated  by  simulation 
or  flight).  This  system  also  provided  the  trajectory  con¬ 
troller  with  inputs  from  the  list  of  maneuvers  in  the  planned 
trajectory. 

The  flight-test  monitor  expert  system  issued  maneuver 
requests  to  the  trajectory  controller,  then  monitored  the  air¬ 
craft  parameters  of  interest  to  insure  that  no  system  con¬ 
straints  were  violated.  This  system  also  monitored  ma¬ 
neuver  quality.  When  a  system  constraint  was  violated  or 
the  quality  of  a  maneuver  was  unacceptable,  the  flight-test 
monitor  expert  system  notified  the  FTE  of  the  problem  and 
made  recommendations  based  on  the  information  within 
its  knowledge  base.  Each  maneuver  was  selected  from  the 
list  of  planned  maneuvers  in  order;  the  flight-test  monitor 
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expert  system  initiated  these  maneuvers  and  then  waited 
for  the  trajectory  controller  to  finish  a  maneuver  before 
proceeding  to  the  next  maneuver  on  the  list. 

4.3  Automated  Flight-Test  Management  System 
Configurations 

The  ATMS  had  three  configurations:  the  FTE  workstation, 
the  simulation  validation  system,  and  the  flight  system. 
The  FTE  workstation  and  the  simulation  validation  system 


were  used  to  develop  and  evaluate  flight-test  plans.  The 
simulation  validation  system  was  also  used  to  aid  in  the 
validation  of  the  flight  system  including  aircraft  modifica¬ 
tions.  The  flight  system  was  used  to  actually  conduct  flight 
test  by  executing  the  flight-test  plan,  monitoring  the  perfor¬ 
mance  of  the  aircraft,  and  controlling  the  aircraft  in  flight 

4.3.1  Flight-Test  Engineer’s  Workstation 

The  configurations  of  the  FTE  workstation  is  shown  in 
Figure  5.  This  system  was  used  by  the  FTE  to  develop 
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Altitude  versus  time 


Fig.  4  Timeline  display. 


preliminary  flight-test  plans  without  having  to  use  the  air¬ 
craft  simulator.  This  provided  the  FTE  with  a  stand¬ 
alone  system  that  was  separated  from  the  aircraft  simulator, 
which  was  always  in  great  demand,  and  thus  allowed  more 
flexibility  in  test  plan  development. 

The  FTE  workstation  included  two  computers;  a  symbolic 
computer  with  a  numeric  processor  board  and  a  graphics 
workstation.  The  LISP  processor  on  the  computer  con¬ 
tained  the  flight-test  planning  expert  system,  the  man- 
machine  interface  system,  and  the  rule-based  portion  of  the 
flight-test  monitoring  expert  system.  The  numeric  proces¬ 
sor  on  the  symbolic  computer  contained  a  three  degree-of- 
freedom  (3  dof)  digital  performance  simulation  (DPS)  and 
the  software  to  execute  the  algorithmic,  trajectory  manage¬ 
ment  portion  of  the  flight-test  management  expert  system. 
The  LISP  processor  and  numeric  processor  board  commu¬ 
nicated  using  an  internal  bus.  The  graphics  workstation 
contained  a  six  degree-of-freedom  (6  dof)  simulation  of  the 
aircraft  and  the  FTTC.  The  two  computers  communicated 
using  Ethernet  with  a  standard  protocol. 

4.3.2  Simulation  Validation  System 

The  configuration  of  the  simulation  validation  system  is 
shown  in  Figure  6.  This  system  was  used  by  the  FTE  to 
evaluate  flight  plans  developed  on  the  FTE  workstation 
to  provide  detailed  pilot-in-the-loop  mission  briefing  and 
familiarization,  and  as  a  validation  facility  for  testing  the 
ATMS  as  well  as  the  ground  and  aircraft  systems  to  be  used 
in  the  actual  flight  testing. 

The  simulation  validation  configuration  of  the  ATMS  in¬ 
cluded  three  computers;  the  symbolic  computer  and  two 
real-time  mini  computers.  The  computer  in  the  simula¬ 
tion  validation  system  was  configured  identically  to  the 


FTE  workstation  configuration  of  this  processor.  One  mini 
computer  (designated  the  “control  law  computer”)  con¬ 
tained  the  trajectory  controller  software  and  communicated 
with  the  symbolic  computer  using  a  standard  protocol.  The 
communication  between  this  mini  computer  and  the  sym¬ 
bolic  computer  was  identical  to  the  communication  be¬ 
tween  the  computer  and  the  graphics  workstation  in  the 
FTE  workstation  configuration.  The  other  mini  computer 
contained  a  detailed  6  dof  simulation  of  the  aircraft  and 
also  contained  detailed  models  of  the  downlink  and  uplink 
telemetry  system.  The  two  mini  computers  communicated 
in  engineering  units  through  FORTRAN  named  common 
blocks  using  a  two-port  shared  memory. 

433  Flight  System 

The  configuration  of  the  ATMS  flight  system  is  shown  in 
Figure  7.  The  flight  system  was  to  be  used  to  conduct  flight 
test  by  executing  the  flight  test  plan,  monitoring  the  perfor¬ 
mance  of  the  aircraft,  and  controlling  the  aircraft  in  flight 

The  flight  system  configuration  of  the  ATMS  included 
three  computers;  a  symbolic  computer  and  two  mini  com¬ 
puters.  The  computer  in  the  flight  system  was  configured 
identically  to  the  FTE  workstation  and  simulation  valida¬ 
tion  system  configurations  of  this  computer.  One  mini  con¬ 
trol  law  computer  contained  the  trajectory  controller  soft¬ 
ware  and  communicated  with  the  computer  using  a  stan¬ 
dard  protocol.  The  communication  between  the  control 
law  computer  and  the  smaller  computer  was  identical  to 
the  communication  between  the  smaller  computer  and  the 
control  law  computer  in  the  simulation  validation  system 
configuration.  A  second  mini  computer  (designated  the 
“engineering  units  computer”)  was  included  in  the  flight 
system  and  provided  processing  required  for  the  uplink  and 
downlink  telemetry  systems.  The  communication  between 
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Fig.  5  FTE  workstation  configuration. 


the  two  mini  computers  was  identical  to  the  communica¬ 
tion  between  the  two  mini  computers  in  the  simulation  val¬ 
idation  configuration.  In  the  flight  system,  the  simulation 
model  of  the  aircraft  and  telemetery  systems  were  to  be 
replaced  with  actual  systems. 

5  THE  EVOLUTION  OF  TEST  .PLAN  FROM  THE 
AUTOMATED  FLIGHT-TEST  MANAGEMENT 
SYSTEM 

The  first  version  of  the  ATMS  was  used  to  develop  the 
rapid  prototyping  facility  for  flight  research  in  advanced 


systems  concepts  [2,10].  This  rapid  prototyping  facility 
was  intended  to  allow  easy  transition  from  concept  to  sim¬ 
ulation  then  to  flight  Not  only  was  ATMS  the  first  system 
to  be  used  in  this  facility,  it  was  the  first  system  to  benefit 
from  the  capabilities  provided  by  this  facility. 

As  originally  conceived,  ATMS  was  to  have  combined  sev¬ 
eral  concepts  into  a  single  system  that  would  allow  plan¬ 
ning,  simulation,  execution,  and  monitoring  of  research 
test  flights.  But  this  was  unachievable  for  several  reasons. 
The  most  apparent  problem  was  the  inadequacies  of  the 
symbolic  processors  and  the  expert  system  development 
language  when  applied  to  real-time  tasks.  Without  this 
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Fig.  6  Simulation  validation  system  configuration. 


facility  these  problems  might  not  have  been  detected  until 
much  later  in  the  development  program. 

The  problem  of  computers  and  expert  system  development 
languages  was  addressed  by  re-implementing  the  expert 
systems  using  CLIPS  (*C  Language  Production  System), 
converting  from  LISP  to  ‘C,’  using  X-windows  for  the 
graphical  user  interface,  and  re-hosting  the  system  on  stan¬ 
dard  numeric  workstations. 

Finally,  experience  in  the  rapid  prototyping  showed  the  dif¬ 
ficulties  inherent  in  a  system  as  ambititious  as  ATMS.  In¬ 
stead  of  a  single  system  to  manage  all  aspects  of  planning. 


simulation,  execution,  and  monitoring,  we  decided  to  de¬ 
velop  several  separate  but  compatible  systems.  Thus,  the 
rapid  prototyping  facility  allowed  realistic  decisions  to  be 
made  about  the  viability  of  the  ATMS  concept. 

TEST  .PLAN  is  the  result  of  the  decision  to  expand  the  por¬ 
tion  of  ATMS  that  provided  the  FTE  with  a  planning  tool. 
This  system,  while  the  development  was  under  government 
auspices,  was  called  the  "flight  test  engineer’s  worksta¬ 
tion”  [3]  and  TEST .PLAN  when  extended  and  commer¬ 
cialized  by  G  &  C  Systems  Inc.  (G  &  C  Systems  Inc.,  San 
Juan  Capistrano,  CA). 
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Fig.  7  Flight  system  configuration. 


6  TEST-PLAN 

TESTJPLAN  is  a  computer  program  designed  to  run  on 
standard  graphics  workstations  (under  either  the  UNIX® 
or  VMS  operating  systems)  as  an  aid  to  FTEs  in  planning 
and  executing  flight-test  programs.  TESTJPLAN  allows 
the  FTE  to  organize  and  file  extensive  amounts  of  planning 
data  while  satisfying  planning  requirements  on  a  flight-by- 
flight  basis  using  aircraft  and  flight  specific  information 


®  UNIX  is  *  registered  trademark  of  AT  4  T  Bell  Laboratories,  Whip- 
pas*  New  Jersey. 


about  instrumentation,  telemetry,  range,  center-of-gravity, 
airborne  and  ground  support,  aerodynamic  configuration, 
system  configuration,  and  payload. 

6.1  TEST  .PLAN  Components 

The  primary  components  of  TEST .PLAN  (shown  in 
Fig.  8)  include: 

1.  A  planning  facility  with  over  1000  flight-test  plan¬ 
ning  procedures. 


Automated  test  planner 


2.  an  extensive  graphical  user  interface  (GUI), 

3.  an  interface  with  a  relational  database  management 
system  (RDBMS), 

4.  an  aircraft  performance  simulation  facility, 

5.  a  flight  card  generation  facility,  and 

6.  expert  system  based  planning  aids. 

In  the  following  sections,  we  will  discuss  these  compo¬ 
nents  of  TEST-PLAN. 

6.1.1  Planning  Facility 

The  heart  of  TEST-PLAN  [11]  is  a  planning  facility 
consisting  of  a  planning  matrix  and  over  1000  plan¬ 
ning  procedures.  The  planning  matrix  consists  of 


flight-test  maneuvers  and  contingency  maneuvers  orga¬ 
nized  by  flights  for  each  individual  aircraft  in  a  flight-test 
program.  The  planning  matrix  is  displayed  in  an  easy  to 
use  format  (Fig.  9). 

The  automated  planning  procedures  allow  the  FTE  to 
plan  flight-test  programs  by  defining  maneuvers  and  fill¬ 
ing  out  the  planning  matrix.  The  basic  philosophy  imple¬ 
mented  in  the  TEST-PLAN  planning  facility  (Fig.  10)  fea¬ 
tures  the  creation  of  a  centralized  database  of  test  points 
in  an  RDBMS  which  must  be  satisfied  in  the  flight-test 
program;  the  creation  of  multiple  flight-test  plans  con¬ 
sisting  of  test  points  assigned  to  flight-test  maneuvers, 
flight-test  maneuvers  assigned  to  flights,  and  flights  as¬ 
signed  to  blocks  of  flights  for  specific  flight-test  aircraft; 
and  continuous,  automated  constraint  checking  between 
test  points,  maneuvers,  and  flights  for  test  point  require¬ 
ments  and  flight  assignments  on  a  flight-by-flight  basis. 
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Fig.  9  Planning  matrix  display. 


6.1.2  Graphical  User  Interface 

TEST-PLAN  uses  graphics  extensively.  One  of  its 
most  visible  features  is  a  highly  developed  GUI  using 
X-windows.  This  interface  consists  of  windows,  pan¬ 
els,  canvasses,  action  buttons,  and  menus.  Maximum 
use  of  is  made  of  mouse  initiated  operations.  The  inter¬ 
face  permits  the  FTE  to  execute  procedures  in  any  order 
desired — the  FTE  is  not  limited  to  the  serial,  predefined  or¬ 
der  of  events  typically  found  in  a  menu-driven  application. 


Using  the  TEST-PLAN  GUI,  the  flight-test  engineer  can 
perform  many  tasks  which  would  normally  require  exten¬ 
sive  paper  and  pencil  work.  These  automated  tasks  in¬ 
clude  laying  out  planning  matrices,  planning  blocks  of 
flights,  defining  test  points,  defining  flight-test  maneuvers, 
assigning  test  points  to  flight-test  maneuvers,  sequencing 
flight-test  maneuvers  to  minimize  fuel  and  time  required, 
writing  flight  cards,  and  satisfying  test  point  constraints. 
These  test  points  constraints  may  be  based  on  instrumen¬ 
tation,  aircraft  configuration,  range  (operating  area)  re¬ 
quirements,  telemetry  requirements,  system  configuration. 
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Fig.  10  The  TESTJPLAN  planning  philosophy. 


air  and  ground  support  requirements,  payload,  weight  and 
balance  requirements,  flight  limits,  trim  point  conditions, 
or  test  point  prerequisites. 

6.1.3  Relational  Database  Management  System 

TEST  .PLAN  is  functionally  integrated  with  the  Oracle  Re¬ 
lational  Database  Management  System  (RDBMS).  The 
RDBMS  contains  a  database  of  test  points  for  a  flight- 
test  program.  TEST .PLAN  incorporates  many  procedures 
which  greatly  simplify  database  queries,  record  additions, 
modifications  and  deletions.  No  special  knowledge  of  the 
database  query  language  is  required  because  TESTJPLAN 
provides  the  user  a  set  of  menus,  action  buttons,  and  data 
entry  fields  as  part  of  the  GUI. 

6.1.4  Aircraft  Performance  Simulation 

TESTJPLAN  contains  a  3  dof  generic  aircraft  performance 
simulation.  This  simulation  requires  the  user  to  define  an 
aerodynamic  model  (of  lift  and  drag  coefficients  as  func¬ 
tions  of  Mad)  number  and  angle  of  attack)  and  a  propul¬ 
sion  system  model  (of  thrust  and  fuel  flow  as  functions  of 
altitude  and  power  lever  angle). 

Using  the  simulation  and  this  simple  definition  of  the  vehi¬ 
cle,  TEST  .PLAN  can  compute  the  trajectory  and  fuel  used 
in  any  of  52  preprogrammed  maneuvers  such  as  climbs,  de¬ 
scents,  level  accelerations  and  decelerations,  cruise,  turns, 
and  dynamic  maneuvers.  The  flight-test  engineer  also  has 
the  capability  of  building  new  maneuvers  by  stringing  to¬ 
gether  combinations  of  individual  maneuvers. 


6.13  Flight  Card  Generation  Facility 

TEST .PLAN  provides  a  flight  card  generation  fadlity 
which  uses  default  entries  from  the  flight  card  database  to 
generate  a  set  of  flight  cards  for  a  specific  flight.  The  nom¬ 
inal  flight  card  is  shown  in  Figure  1 1 .  However,  the  format 
can  be  customized  to  any  desired  during  the  customization 
portion  of  an  installation  of  TESTJPLAN. 

6.1.6  Expert  System  Based  Planning  Aids 

TEST .PLAN  contains  two  expert  system  planning  aids: 
a  flight  planner  and  a  block  planner.  The  block  planner 
assigns  maneuvers  (which  contain  test  points)  to  flights, 
attempting  to  minimize  the  numbe  .  flights  required  to 
execute  the  maneuvers  within  the  otock  while  satisfying 
constraints  on  instrumentation,  configuration,  flight  lim¬ 
its,  flight  conditions,  prerequisite  test  points,  and  range  re¬ 
quirements.  The  flight  planner  reorders  maneuvers  within 
individual  flights  attempting  to  satisfy  constraints  while 
minimizing  fuel  and  range  lime  used;  the  flight  planner 
uses  fuel  and  time  data  obtained  from  trajectories  gener¬ 
ated  in  the  performance  simulation.  An  explanation  facil¬ 
ity  is  provided. 

7  CONCLUDING  REMARKS 

This  report  describes  the  automated  flight-test  manage¬ 
ment  system  and  an  automated  flight  test  planning  sys¬ 
tem  called  TEST .PLAN.  The  evolution  of  TESTJPLAN 
from  automated  flight-test  management  system  is  detailed 
to  illustrate  the  use  of  rapid  prototyping  to  define  system 
requirements. 
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Fig.  11  Nominal  flight  card  format. 
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KEYNOTE  ADDRESS 

by 

Major-General  W.  Breeschoten 

Ministerie  van  Defensie  (KLu) 
Luchtmachstaf 
P  O  Box  20703 
3300  Es  Den  Haag 
The  Netherlands 


I.  INTRODUCTION 
Ladles  and  Gentlemen, 

In  addition  to  my  present  function  as  Director 
Operations  of  the  RNLAF  I  an  a  fighter  pilot. 

This  week  you  will  be  discussing  ny  Job;  the 
management  and  control  of  nissions. 

Therefore  I  was  pleased,  both  with  the  subject  of 
this  symposium  and  with  your  kind  Invitation  to 
address  you  at  the  beginning  of  this  week. 

In  this  address  I  will  start  with  my  views  as  a 
pilot  on  the  subject  of  mission  control  support 
systems ,  (you  already  noted  the  word  support)  and 
work  towards  my  views  as  Director.  These  views 
are  the  sane,  only  the  scope  is  different. 

II.  MISSION  CONTROL  AND  THE  PILOT 

As  a  pilot,  or  group  of  pilots  I  get  assigned  a 
mission,  say  to  attack  a  certain  ground  target 
with  the  objective  to  destroy  it,  or  make  it 
unusable  for  a  certain  period  of  time.  My  job 
then  is  to  prepare  and  execute  this  mission. 

My  preparation  consists  largely  of  building  up  an 
image  of  what  precisely  is  required  and  under 
what  circumstances. 

For  this  I  collect  information  on  the  situation 
enroute.  the  situation  at  the  target,  the 
assistance  that  can  be  expected  from  supporting 
forces  and  when,  the  weather  situation  and  so  on. 

Then  the  mission  is  planned,  which  concerns  a 
multitude  of  items: 

route  selection,  flight  profile  planning,  weapons 
selection  and  attack  profile  planning,  planning 
for  mutual  protection  ,  planning  for  ECM 
employment,  planning  for  threat  system  counters, 
not  to  mention  planning  for  relative  timing  and 
required  command  and  information  exchanges  with 
my  companions  with  supporting  units  and  with 
other  missions. 

Now  I  know  what  I  can  expect  during  my  mission 
and  how  to  manage  possible  situations.  Also  I 
know  how  these  situations  can  be  identified, 
using  my  on-board  sensor  data.  For  situations 
that  car  be  anticipated  I  know  what  I  am  supposed 
to  do  and  hov  to  do  it. 

During  execution  I  use  the  preparation  results  in 
conjunction  with  my  system  displays  and  my  mkl 
eyeball  to  maintain  an  image  of  the  situation, 
assess  its  meaning  for  my  mission,  decide  on 
actions  and  of  course  carry  them  out. 

This  process,  from  preparation  to  execution,  is 
called  mission  control.  In  the  complex  technical 
and  operational  environment  of  today  and  tomorrow 
I  can  do  with  some  nelp  when  doing  it. 

First  of  all  in  the  field  of  information  during 
preparation.  The  more  I  know,  the  less  surprises, 
and  the  larger  rhe  chance  of  a  successful 
mission.  Therefore  Information  must  be  recent, 
reliable,  and  preferably  accurate  and  complete. 


Most  of  all  it  must  be  easy  to  interpret. 

For  instance,  I  want  to  know  what  my  target  looks 
like  now,  not  last  week;  where  precisely  it  is  or 
is  expected  to  be,  and  what  tricks  can  be 
expected  in  terms  of  decoys  camouflage,  defenses 
etc . 

Then,  when  planning  my  mission,  I  certainly  like 
support  in  clerical  tasks. 

Let  a  system  calculate  my  fuel  use  for  me,  plot 
my  route,  identify  the  risk  when  engaging  threats 
for  the  tactics  selected,  document  my  planning 
for  me  and  prepare  my  system  data  loader  for  me. 
Let  it  allow  me  to  assess  the  consequences  of  an 
info  update  at  the  end  of  my  planning  process  and 
make  it  possible  to  adapt  the  primary  plan  if 
necessary. 

During  my  mission  I  would  like  my  systems  to  show 
me  the  situation  in  an  easily  understood  manner. 
Show  me  relevant  information  only.  I  could 
indicate  premisssion  what  I  consider  relevant  and 
what  not.  It  can  also  show  me  my  own  capabilities 
in  relation  to  threats. 

You  will  notice  that  I  stress  the  information 
supply  side,  and  the  improvement  of  the  quality 
of  information,  to  make  it  directly  accessible 
for  the  pilot,  without  the  need  to  interpret  raw 
data. 

I  do  not  want  the  system  to  think  for  me,  at 
least  not  in  the  sense  that  it  prescribes  my 
tactical  actions. 

It  can  to  some  extent  think  with  me.  For  example 
to  carry  out  some  tasks  that  I  do  not  wish  to  be 
bothered  with;  it  may  monitor  my  other  systems, 
decide  which  ones  do  not  perform  correctly,  re¬ 
configure,  and  inform  me  of  any  degradation  in 
?rformance ,  not  redundancy. 

Also,  if  I  want  so,  a  system  can  perform  specific 
tasks  for  me,  for  instance  do  my  self -protection, 
activate  and  shut  down  jammers  and  throw  decoys, 
provided  its  operation  is  transparent,  which 
means  that  I  know  what  it  will  be  doing. 

More  in  general,  the  functions  of  systems  that 
support  me  need  to  be  clear.  I  have  to  understand 
what  their  products  mean. 

For  route  planning  I  like  a  system  that  shows  me 
the  known  threat,  and  indicates  what  possibly 
could  be  there  that  is  unknown  ac  present. 

I  certainly  do  not  want  a  system  chat  calculates 
an  optimum  route  for  me  under  the  erroneous 
assumption  chat  the  world  is  known,  with  the 
result  that  I  have  to  meander  towards  my  target 
and  then  run  into  a  few  surprises  all  the  same. 

It  is  imperative  that  mission  control  support  for 
manned  systems  Is  designed  in  such  a  manner 
thatit  supports  the  pilot,  or  more  in  general  the 
operator.  If  he  can  not  maintain  a  clear  image  of 
the  situation,  he  cannot  perform  his  job.  Also, 
if  the  supporc  systems  do  perform  part  of  his 
primary  job,  he  does  lack  the  freedom  of  control 
he  may  need.  And  if  you  let  the  system  do  it  .’11, 
you  do  not  need  a  pilot. 
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